ZigZagJoe

Seems like un-needed complexity, overall; dev time could be more profitably spent elsewhere. Everything you've listed has degradation measured over tens of years - even batteries (look up nickel-hydrogen batteries). With mission times in KSP typically being far short of that, it's just unneeded complexity. If KSP was a 110% realistic space exploration simulator, sure, it'd be a good idea to implement degradation due to age and environmental factors. But, KSP is a game, and so it doesn't make sense to add a glut of parts and mechanics that add so little. The stuff about fuel tanks I've got no idea where, how, or why you've come up with; it's complete nonsense. Fuel tanks do not require electricity to maintain the fuel; it does not degrade. Technically, if you want to be anal about it, they can require stirring (the part which failed in apollo 13) to maintain consistency when on standby for immediate use, but again this fails the complexity test. Likewise, we can safely assume that fuel tanks are designed with an appropriate degree of shielding to deal with solar heating concerns. KSP is not a graduate level course in spacecraft flight and design, preparing to work at JPL - it's a game.

CPU physics calculation tends to be the primary bottleneck in KSP as part counts climb, but the GPU is by no means sitting idle - KSP would run absolutely glacially if it were using purely software rendering. Real life example: If I forget to turn on the 9600 GT and just use the 9400m, well, let's just say there's a painfully obvious difference in FPS. So, no, you are flat out wrong. Also, the GT415 was the lowest GPU of its class and is actually inferior to the intel HD 4000 - I'm not surprised you are having to use very low settings. I'm guessing it's paired with either an i3 or an AMD chip. If it's the latter, you're boned. KSP may not look like much but it's fairly intensive all the same - unlike portal 2, which is technologically a very elderly game. As long as you are staying around 100-150 parts or less, you should be able to do /ok/, but more than that and things will get very slow very quickly (assuming you don't have an AMD chip). If you /are/ cpu bound, then you will have slow gameplay speed due to time being slowed down with either high FPS (no vsync) or low GPU utilization (vsync on).

I play on a Mid-09 myself. Slow opening save file - how many flights are active? Low framerate in atmosphere: Normal, especially if aerodynamic FX are happening. Lower terrain detail may help. Framerate drop while maneuvering: Normal. CPU Usage: normal. You've got a good CPU; it won't be a bottleneck until you've got 300 parts or more. Your biggest problem is GPU - you need to be using Simple render quality, Half res textures, No antialiasing, Low terrain detail, Very Low/minimal Aerodynamic FX. You may need to lower these settings further; these are the settings i use for the elderly 9600 GT in my macbook, and intel HD 4000 are about 25% slower than that. You're okay memory-wise unless you've got most of that 4gb eaten up before you launch KSP. Look at Activity monitor, sum the 'Free' and 'Inactive' memory counts and make sure you have 1.5 - 2gb available. That being said, it's maybe 30$ to upgrade to 8gb, I'd recommend it, but don't expect it to fix it. Gameplay wise, optimize for part count. Fewer parts, the better performance you'll get.

I love you. Nothing like shooting down misinformation with extreme prejudice. Only one minor thing to note - if you are using XP, the scheduler is unaware of which logical cores are on the same physical core, and so it's *possible* for two CPU-intensive threads to run slower. Still, extremely niche case. This is a nonissue in w7 - and i'd assume in vista+w8 too - as the scheduler is aware of which logical cores share physical cores and so schedules threads appropriately. Oh, and for additional hilarity, the only way a single physical core would effectively run two logical threads at half speed is if both threads were no more than while(true) loops. In real world usage scenarios the worst-case performance per thread given two on the same physical core tends to be around 65-75% - assuming both would use 100% if they could. Depends on the type of work, of course. Edit: Oop, i see the original OP (who is being responded to by this thread) mentioned using W7. Yep, complete FUD and/or placebo effect.

Another cargo spaceplane! The 'Hackjob', thusly named as it's a previous plane cut in two with minor modifications and of course the cargo section inserted. 62 parts, stock. craft file. ~15 tons fueled with no cargo. Exactly half of the capabilities of the 'Tubby' spaceplane featured in my previous post: 4.5 tons to orbit with maneuvering fuel, or 5 tons to orbit only. Also, no, not twisty at all due to strutting on the backbone-beam of the cargo area. Comparison to tubby cargo spaceplane.

Latest and most favorite SSTO: Tubby X Cargo Spaceplane - Stock, 86 parts, 28 tons without payload, lifts up to 9 tons of cargo unaided with dV to spare for docking. Payload capacity dimensions roughly that of an orange tank. Not much of a looker, but very useful. Mechjeb is optional but useful solely for the flameout prevention feature - it can be sort of really hairy managing the zoom climb unaided. Doable, but hard, especially with cargos near payload max. Freshly deployed station core. More pictures: http://imgur.com/a/cVKUh Craft files (6): http://ridetheclown.com/downloads/TubbyX.zip First spaceplane: Stubby X. Stock, 48 parts. VTOL capability - hence the two tiny rockets up front. It's been superseded as a SSTO, but retains a place in my heart. Originally based on a little VTOL atmospheric runabout design, just banged on two lv909 pods + extra tank and called it good. Stublonger VI: first nuclear spaceplane. Stock, 50 parts. Little Pig II: minimalistic spaceplane. 37 parts. Non-nuclear - two LV909s.

Always wanted to make a spaceplane with a central cargo bay, finally succeeded after discovering a few extra laws of physics. Presenting the Tubby medium-duty cargo spaceplane: Freshly deployed station core. More pictures: http://imgur.com/a/cVKUh Pictures are of an earlier revision, but aside from gear location and fitiment they're basically the same. Craft files (4): http://ridetheclown.com/downloads/TubbyX.zip 86 parts - STOCK Fueled, weight: 27.8 tons Payload capacity: 9 tons Payload dimensions: Roughly orange fuel tank + a bit left and right Propulsion: 4x Turbo-jet (10 intakes), 2x Atomic, 6x Sm. Radial Fuel: 200 monoprop 450 LF (jet fuel) 720 LF / 880 OX Center of mass should be around the end of the rocket fuel tanks. Flight profile: - Rapid climb to 22km on 90 degree heading, 60 degree inclination. - Slow climb to 24.5km @ 1525m/s airspeed: engage main engines (2) and boosters (3); Zoom-climb at 55 degrees - Jet engine shutoff at 29km (1) - Booster shutoff (3) when Apogee >= 34km. May be reduced in duration or skipped entirely if payload is light. @ 50km: burn at 15 degree angle until Apogee is > 80km @ Apogee: burn at 0 degree inclination towards 90 degree heading until orbit circularized Climb angle may need to be increased if near max of payload capacity. Notes: In orbit, should have 33% of jet fuel (150/450) and 15-70% of rocket fuel (dependent on load) remaining. Slightly wiggly with no payload and full fuel load. Returns to kerbin with no issues after payload delivered. Tendency to nose down below 1km at full load, but is fine afterwards. Make sure to watch air intake and reduce throttle accordingly when executing zoom climb maneuver. This is the most crucial part of the whole exercise - if you flame out and start spinning, you will likely lose too much time if lifting a heavy payload. Watch that you don't clobber the engines/payload on take off. 9 tons is the max limit for having any sort of orbital maneuvering ability, such as docking with a station at 100km. You might be able to sneak 10 tons into a 70km orbit, but no fuel for any orbital stuff would be left.