KSP orbiter

Yeah, and now that you mention it that's a bit of a concern. We all know how big space is and how long it takes to get anywhere, even with time acceleration. But we can put our ship on the proper trajectory and just accelerate time until it gets there, so it isn't too painful. A few mid-course correction burns are the worst it gets. The problem is that we can't do that with rovers - they have to be under control at all times they're moving. And that slows things down a lot. I've never managed to get a rover much over 20 m/s, and even at that reckless pace it can still take a long time to get where you're going. I'm starting to wonder if this is going to require some sort of auto-drive system (another good thing to hang off the science tree...) - just something that tries to go from point A to point B, and calls for attention if it runs into something it can't handle. At least that way your rovers could rove while you're doing something else.

I like the idea of giving the player more freedom to choose what sort of research they do, and being able to choose what experiments you put in each Science module for a given flight would be an excellent way to make them more reusable. The game needs to have a layer of abstraction over what is being done in order to make it a game, so I wouldn't push for too great a level of detail. The number of science types should be small enough that it's not overwhelming, but large enough that it either allows or forces the player to make meaningful choices about what they'll research. I favour perhaps 6 or so fairly broad topic areas: Electronics (Blue) Aerodynamics (Yellow) Materials (Orange) Fuels or Chemistry (Red) Life Sciences (Green) Information Sciences (Purple) It might be possible to have each part be unlocked seperately, but in any case the types and quantities of science needed to unlock something should bear some resemblance to what it is or does. New fuel tanks might require mostly orange science, with small quantities of red and yellow. The 'Hitchhiker Storage Container' would be mostly green and orange, with a little blue and purple. That's just an example for purposes of discussion, of course. What do people think should be on the list of areas to research?

Just throwing an idea out here, but would having different types of 'Science' help give a bit more definition to discoveries and the tech tree? For example you might earn different kinds of Science points for conducting different experiments. Things relating to chemistry ('red science'), or aerodynamics ('blue science'), or life sciences ('green science') and so on. Nodes on the tech tree would require differing quantities of each - a new command pod might require advances in electronics and life sciences, but you don't need any improvements in chemistry or aerodynamics. This would also tie in to allowing the player to choose what experiments they want to run, in order to unlock the parts they want. "Hmm, I want to build multi-stage rockets, but I don't have enough red and blue science to unlock decouplers... better run some experiments in those areas." "Now I need more powerful engines to lift the multi-stage monstrosity that I've created! Or better fuels... which one to go for?"

I think this is a good point. The preflight checklist especially is a good idea, and it wouldn't stop people from ignoring it or turning it off. Generally speaking, the new-user experience in KSP is not all it could be. The documentation and tutorials haven't really kept pace with other aspects of the game, and feedback like this is valuable because it shows some of the gaps that remain to be filled. The game is still in alpha, so it's not too much of a problem at this stage, but there's certainly ample scope for improvement when the time comes.

You make a good point about the composition of the atmosphere. "It would be like filling a balloon with air and expecting it to float." But we do exactly that already. Hot-air balloons aren't great, but they do work pretty reliably. Perhaps something like that would be more practical.

Airship parts have obvious immense utility for probing the atmosphere of gas giants too. Eventually we're going to need something like that, there's only so much data a probe can send back as it parachutes towards crush depth.

I'm not surprised that it doesn't steer well. I'm surprised that it steers at all.

I tried a new lander design, which didn't have quite enough fuel tankage. Because I was trying to save fuel, I didn't kill all the horizontal velocity before touching down. Because I didn't kill all the horizontal velocity, it tipped over. Because it tipped over, one of the truss-mounted engines broke off. So now I am developing a new new lander design, which can rescue the original crew from their broken, radiation-spewing, spacecraft.

As others have said, welcome aboard. And don't forget to Dream Big. When Kerbals dream, they build that dream. When they launch that dream, it will blow up. And when it blows up, another dream is fulfilled.

Playing since 0.8.3, bought it as soon as I could. 0.13 or so? Best US$7 I ever spent.

I'm just going to leave these real-world rules here... 1. Engineering is done with numbers. Analysis without numbers is only an opinion. 2. To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong . 3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. 4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. 5. (Miller's Law) Three points determine a curve. 6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker. 7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it. 8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point. 9. Not having all the information you need is never a satisfactory excuse for not starting the analysis. 10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along. 11. Sometimes, the fastest way to get to the end is to throw everything out and start over. 12. There is never a single right solution. There are always multiple wrong ones, though. 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. 14. (Edison's Law) "Better" is the enemy of "good". 15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. 16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours. 17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct. 18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though. 19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up. 20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately. 21. (Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which. 22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.) 23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. 24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it. 25. (Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along. 26. (Montemerlo's Law) Don't do nuthin' dumb. 27. (Varsi's Law) Schedules only move in one direction. 28. (Ranger's Law) There ain't no such thing as a free launch. 29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right. 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept. 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees. 32. (Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up. 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week. 34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have. 35. (de Saint-Exupery's Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. 36. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective. 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame. 38. Capabilities drive requirements, regardless of what the systems engineering textbooks say. 39. The three keys to keeping a new manned space program affordable and on schedule: 1) No new launch vehicles. 2) No new launch vehicles. 3) Whatever you do, don't decide to develop any new launch vehicles. 40. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...) Taken from http://spacecraft.ssl.umd.edu/akins_laws.html

I\'m awestruck. Well done, and done well.

Thanks so much for posting this! Thanks to that, I\'ve finally made it to a safe landing on the Mun.

That is simply incredible. I\'m amazed you could get the thing into orbit, much less half way to the Mun!

Received my pre-order email this morning, thanks!