av8r1

The current game makes you upgrade the research center before you can transfer resources, right? Given that, if the clamp-o-tron Jr. was available before that point, you could use the Mk. 1 command pod to perform very Gemini-like missions, in which docking was the whole goal of the mission. Advance a bit through the tree, and you can transfer resources. Shortly thereafter, you get the clamp-o-tron classic, which allows for more Apollo-like performance where you can easily transfer crew and supplies back and forth. Finally, you get the clamp-o-tron Sr., which I agree is pretty much only good for space station construction. A small tweak to the tech tree and the existing parts can provide quite a bit of emergent gameplay. As it is, I go from Mercury-style orbital missions immediately to a moon mission, often by adding legs to my command module and a bigger booster. Having additional Gemini-like goals of EVAs, dockings and orbital maneuvers before "Explore the Mun" would be pretty fun I think. Here I'll admit that I haven't ever used the COT Sr. Since I can launch every single space station part on one rocket, and most actual ships use the normal size, I haven't found a need for the biggest one.

Okay, so there's a way to accomplish my goal, but it's unintuitive and inelegant.

I've come up with an Apollo-like system of spacecraft that work to explore each planet. It consists of a small space station for science processing and refueling, a CSM-like crew return vehicle, a lander, and a reusable rover that can reattach to the lander via a Clamp-O-Tron Jr. But, each planet or moon has it's own hardware requirements. My rover is practically useless on Minmus-sized bodies for lack of traction, so I might as well not take it with, opting instead for more fuel. For planets without atmosphere, barometers and parachutes are useless so I might as well not take them. So I would like to be able to build each component as a subassembly and stack them together with minor modifications to each so I can spend less time building the same parts from scratch over and over again. Problem is, the subassembly system seems to be designed specifically to prevent this. Build anything resembling a whole space ship and inevitably it says the part is "unattachable." I've never once been able to just glue on my standard rover or lander to a stack. You can't start with a subassembly, so you can't do "I want to launch *this* ship with *this* booster, change this Poodle to a Skipper, and go." Unless I just don't know what I'm doing.

So I've played a bit of career mode, both in .24 and .90, and I have a few suggestions for mission contracts. Reduce the number of component test missions, because they're really tedious. Some are easy money, like testing a stack decoupler on the ground, but others make little sense, like testing an SRB or other lower stage component at high altitude. Instead of "one component at this narrow range of altitudes and airspeeds," maybe do "test these three components on the same rocket and recover them after flight." Test flight contracts are a part of space flight, but maybe they could be less grind-tastic? In a similar vein, I notice that's basically all you get between orbital missions and your first Munar mission. Coming up with the science points to buy both a fuel line and a solar panel is a bit difficult. The new "recon" missions add some neat variety, but would be better executed by plane than rocket. Having enough parts around to build a simple airplane would be appropriate. The contract system could also be used for player training. For instance, I had no idea you could switch between multiple vehicles using the [] keys until I got a rescue mission and had to look it up. These missions would be a great place to introduce how components work and how to control them in-campaign. On a last note, I would revamp the way the mission text works. On most of the contracts, there's some nonsensical fluff text up top and you have to scroll down to see what you actually have to do. It makes finding a contract you want to do a little more tedious. Putting the fluff text at the bottom would fix that.

I did find it a bit jarring that idle kerbals on EVAs just stand there like they're at attention. In the older versions, I didn't see a need to have more than one kerbal out on an EVA since there was barely enough for one kerbal to do, but now that they have specialties there's more of a gameplay emergent reason to do so. I see two potential levels of idle kerbal behavior: Idle animations. These should be the easiest to implement; a given kerbal stands in place and looks around, picks up rocks, looks up at the sky, plays with his suit, and does other cute little things. Maybe even they occasionally jump in place. Some of these could be context-specific. Looking up at Kerbal with an expression of awe would make sense on the Mun, but not so much on Duna. If within a certain radius of a flag, they could salute, and so on. AI wandering. This is where kerbals wander around. I don't like this option because there's a lot of dangerous terrain in the Kerbol system, and the last thing I need on a mission is to have my pilot wander into the Mohole. It would require pathfinding, slope detection (so they don't walk off a cliff), and take up processor power to handle something you might not be looking at. One feature might be to have them magically jetpack back to where the player last put them if their altitude or position changes too rapidly without using up propellant. Wandering off a cliff and jetpacking back up is a very kerbal thing to do. So that they don't get squished by moving craft, having them run tangent to the motion of an object approaching them would be appropriate. That's assuming a surface EVA. A flying EVA is a whole other matter. Little things like waving are okay but I wouldn't have them change positions by themselves. Two things could happen there: the player wouldn't notice, or it would inconvenience the player. Having a kerbal tumble in space while the player isn't controlling him is fine, as long as he stops when the player resumes control.