LameLefty

This. This. A thousand times, this. I would personally also love to see the Career Mode and Tech Tree incorporate some random failure modes, even if it's only an optional feature that most choose to turn off. A newly-unlocked advanced engine part should not be as reliable as one in operation for (simulated) years or decades. Huge solar arrays should jam up, break or become less efficient over time, just as in real life. Antennae should get stuck. Ideally, these things should be repairable by an intrepid EVA crew member equipped with a handy Space Spanner, a roll of Space Tape and enough pluck.

LRO (Lunar Reconnaissance Orbiter) is still there and still in operation. http://lro.gsfc.nasa.gov

My advice is just various combos of all of the above combined with this: PRACTICE! Launch lots of ships and targets and just practice. Dock. Undock, change orbits slightly, wait a few orbits and dock again. Repeat until comfortable. Using the navball is key; everything you need is there and in the Map markers. One thing I'll add is that you do NOT need 12 RCS quads. What you need is RSC balancing, however many blocks that takes for whatever you're trying to maneuver. For a small capsule or probe-controlled stage or module, you might only need 4 quads; take a look at the layout of the Apollo CSM stack, for instance. For a long, heavy rocket stage you might need 8 (four at each end) or yes, maybe even 12. But it depends. Practice, practice and more practice and then is just "clicks" and becomes easy. Just remember to build your RCS layout with COM in mind and do it symmetrically.

Astronautix is good but, well, the author's info is often incomplete or not very well-sourced, and often the descriptions editorialize based on some questionable data. If you have access to a usenet archive (does Google Groups still exist?) check out posts from the old sci.space.history group. Some of the regulars in that group REALLY knew their stuff; heck some of them were the engineers and program managers who worked Gemini, Apollo, Skylab, ASTP, and Shuttle. A lot of others had archived all the old NTRS (NASA Technical Reference Service) documents on every obscure space program or proposal ever made, pretty much. In the modern, post-Usenet era, the next best thing is the forum here: http://forum.nasaspaceflight.com/index.php?board=25.0 Some of the old sci.space regulars have turned up there, and there quality of information is very, very good.

I LOVE this mod! It's one of the final touches I always put on all my spacecraft. And thank you for not including them in the "Lights" group. I use a special action group that toggles the lights through their modes and I use the same setting/action group for every vessel. The "Lights" group is fine for landing lights and headlights on rovers and whatnot, but I don't want that control to mess around with my Aviation Lights settings. I will be downloading as soon as you do. Seriously, this is a truly excellent addition to the game. Thank you for making it.

"We've never tested this rocket before, we don't know if it will stage properly, or if it will fall apart structurally upon launch. We've run no analysis regarding power consumption or the appropriate amount of RCS fuel to load." "And, your point is .... ?" "Let's send it to the Mün!"

Test flew a few things. Crashed things. Back to the VAB!

Lighten up, Francis. It's just a game. If you want realism, use STK.

Because this whole concept is adding complexity to what is (remember) a game. If you want to play around with spacecraft trajectories using "real math", get a copy of Satellite Toolkit and do it the way ULA and SpaceX do it for real. Adding this to KSP may be an amusing intellectual enterprise but (as someone who used to do real-life spacecraft engineering for a living once upon a time), it sure doesn't sound like a game anymore. If you have more than a couple of spacecraft in play and you don't set pretty wide hysteresis bands on your control and alert systems, you'll probably find that your ships are running out of fuel way more quickly than you might think. So, that's the problem with doing just that. But whatever floats your boat.

Thanks for this; I love the KW Rocketry pack and use it a lot but it's a memory hog. This optimization ought to really help!

ASAS is reaction-wheels. That doesn't really get you translation, it gets you attitude control. You need to be able to accelerate to maintain orbit. You might could kludge together something to pretend that the reaction wheels have some kind of ability to accelerate the entire spacecraft arbitrarily, but you're ignoring physics if you think it can do so without some kind of RCS to allow for momentum desaturation maneuvers. And why go to so much trouble to more accurately model the trajectories if you're going to have to then make the cartoony-physics of ASAS even less accurate? Then you'll have to keep track of fuel usage over time for all those vessels, probes, stations, etc. scattered throughout the system, and find a way to alert the player in case one of them depletes the supply, won't you?

You didn't. You also didn't say why anyone would need it otherwise.

Did you watch the Squadcast last night? Harvester said that, other than the few names "hardwired" into the game like Jeb, Bill, Bob, Gus and a few others, the game pulls a couple syllables together from a pool and comes up with a new name. There are something in excess of 10,000 combinations and they've never seen the system generate duplicates even after killing a LOT of kerbals.

Great post down KSP History Lane, but minor correction on the real-world history. The first docking was Gemini 8 to the Agena Target Vehicle (Neil Armstrong, commanding, and David Scott, pilot). There was a Gemini RCS malfunction almost immediately after docking and the mission had to be aborted after an uncontrollable roll developed. Armstrong saved the lives of himself and Scott by thinking quickly and making the right calls to save the spacecraft using the re-entry RCS system. Anyway, otherwise I loved seeing this "ancient" thread come to life, necro or not.

That's an interesting thought, but of course the existing science parts (sensors, that is) will still give us Science!â„¢ when coupled with an antenna to return the data. So perhaps we won't get a mini-science bay, at least not early in the Tech Tree, but we will be able to unlock one after returning enough sensor data and turning our accumulated Science!â„¢ into a Science Bay through the R&D Center.

Exactly. I try to put landing lights on all my landers these days, not just for night/darkside landings, but because they help shown terrain slopes and irregularities that are otherwise less obvious during descent. I still sometimes have to waste more fuel than I'd like "pulling an Armstrong" (a la Apollo 11) and translating to find a more level or less irregular spot.

The previous responses show how to get your orbits into matching planes to enable a rendezvous (and ultimately, docking). I'll add one point - it's a LOT easier to set up a rendezvous and docking by launching the two vehicles into the same plane, or at least very close to the same plane, to begin with. As noted above, plane change maneuvers take a lot of ∆v and hence a lot of fuel. As an aside, I'll note that avoiding large plane changes is the main reason why most real-world missions have limited launch windows; they cannot afford the hit to mission performance needed to make very large plane changes. So they avoid the issue entirely by launching in-plane or as close to in-plain as they can manage.

That is awesome for any number of reasons. (But of course, for historical purists, we have to note that two Gemini vehicles never docked to one another despite the Gemini VI/VII rendezvous; they were incapable of doing so. The docking scheme was not androgynous and required one vehicle to have an active docking mechanism and the other to have a passive target to be clamped or grabbed by the active docking vehicle). Still, very cool. I may have to download and play around with the Gemini vehicle mod!

For the purpose of this discussion, especially with non-technical people, it's a distinction that makes no difference. And in case others wish to consider the matter further, Wiki has a decent article, replete with extensive footnotes and references. Pay special attention to the original 1795 definition of the gram, then go back and re-read my post, in context. http://en.wikipedia.org/wiki/Gram And lastly, this thread serves as a good reminder to us all to keep Wheaton's Law in mind at all times: http://knowyourmeme.com/memes/wheatons-law

I'm an engineer. I've known this since high school, way back in the days of stone knives and bearskins, shortly after the period of time when dinosaurs roamed the Earth. Save the pedantry.

When SI units were first defined way back when, the gram mass was indeed defined to be the equivalent of one cubic centimeter of (distilled) water. It's not defined that way NOW, but a couple hundred years ago, it was.

Personally, I'm looking forward to the challenge of the more constrained system. The sandbox game is awesome and I will always play it but, as MaxMaps (?) mentioned in Friday's SquadCast, one of the goals of Career Mode is to lower the "barrier of entry" for new players so they are not totally overwhelmed with options as they begin to learn what to do and how to do it. Much like a good novel, you can start small-scale (Local farm boy in village ... ) and expand the scale as you go (... is in fact the foundling orphan of the last king. Or whatever; there are infinite variations). Here it will be the same thing. I guess someone, ostensibly Wherner von Kerman, will introduce you to his rocket lab and a handful of parts, tell you we need to orbit this experiment, or at least loft it to the upper atmosphere, for reasons ("To do SCIENCE!") or some such. You try, and as a new player, blow stuff up, but earn Science points for the effort. Repeat a few times if necessary, get enough Science and bingo - a bigger engine, or more efficient one, gets unlocked. Now maybe we have to orbit more or different experiments, or maybe toss one to the North Pole, etc. In a few years' game time you're sending a Kerbalized Mariner to Eve or Duna with Jeb and Bob and Bill seeing who has the Right Stuff back at the Astronaut Center ... I think it has GREAT role-play potential.

All day playing around and I haven't duplicated my problems from last night. May have been user error (probably was) but if it does show back up, I'll report with details. But today, since things are all hunky dory, I just want to say thanks, this has made docking (something I'm already good at) almost effortless. So, well ... thanks!

The space station design I was having trouble with is uses the standard Rockomax HubMax multipoint connector with standard Clamp-O-Tron docking clamps mounted around it radially. The transfer stage design I was having issues with just has a standard 2.5m tank with standard Clamp-O-Trons mounted around it. I'll try again today under more controlled conditions and try to take some good screenshots. If the problem persists (and isn't just a glitch with last night's session), I'll post more details and pics.

I love this mod but I'm also having a problem; it doesn't seem to happen every time but sometimes - despite designating the correct port as the target and designating the port in the active vessel as the "control from" part - the mod ignores the targeted port and seem to aim for the center of mass of the target vessel. The navball markers are correct but DAPI markers are all offset. Even once I'm actually right about to make contact and dock, the DAPI indicators all show I should be missing the port entirely. It's very odd. I've had this happen when targeting two different space stations and a nuclear transfer stage I use a lot from the KW Rocketry pack. One thing they all have in common is a single axial docking port and 4 radial ports. Maybe having so many docking ports in such close proximity is confusing the plugin code. I'll try to narrow it down some more tomorrow.