Hotaru

Docking ports of different sizes don't work together. You can connect them in the VAB and they will be able to decouple, but you won't be able to reconnect them in flight once separated unless they were the same size. In fact you can connect any part to a docking port in the VAB like this and have it decouple in flight, which can be useful (for instance) for putting a launch escape system on top of a capsule. The LES can be jettisoned by decoupling the docking port using an action group, removing the need for an additional decoupler.

No, that is not what I really mean. It's not even true, frankly. I don't particularly care one way or the other, seeing as I'll be buying the expansion pack anyway. Please don't put words in my mouth. I meant exactly what I said. Which is, in my opinion parachutes should be free. You seem to be reading that as I am entitled to free parachutes, which is a completely different statement. Let me put it another way. Squad is perfectly entitled to develop and sell whatever they want, and we will buy it or we won't. We the users are also perfectly entitled to our opinions on what Squad should and shouldn't sell, for whatever reason. Maybe we think they shouldn't do a thing because we believe it would be bad for business. Maybe we think it's dishonest. Maybe we feel we're being taken advantage of. Maybe we just don't like the direction they're taking the game we care so much about. Any of those are perfectly valid reasons for saying Squad should or shouldn't do a thing. You seem to be intentionally making a point of misunderstanding the word "should," for reasons I don't understand. It's not an "absolute moral judgement" or any such thing, it's the opinion of whoever says it. "Should," "would be best if," "would be wrong not to (for some reason)," "would prefer if," all those are roughly equivalent. Even saying something as universal as "you shouldn't steal" is not far off from saying "based on the system of morality I subscribe too, stealing is wrong," which is still just a statement of opinion.

Again, out of likes. One thing I find kind of entertaining about this whole thing is that while lots of us assert that one part or another of the DLC should be stock, everybody seems to think different parts of it should be stock. For me, it's parachutes. Parts seem like perfect DLC material. Some other people say the parts should be stock, still others that the mission editor should be stock, and so on. And if they made everything that anyone said should be stock, stock, I think the DLC would be down to just the alternate spacesuit. So on the whole, I'm not that bothered about it. In the end I have no problem going along with Squad's judgement about what does and doesn't belong in DLCs. That won't stop me having my own opinions on the subject, but it won't stop me buying them either.

Unsurprisingly, I've expended my supply of "likes" for the day, but I agree with everything you said... ...except this. There's no such thing as must, surely (beyond the obvious must turn a profit), but should is completely subjective. What I think Squad should do, what you think they should do, what they think they should do, all of those things are perfectly valid opinions. Of course some of the rationales behind those assertions might be proven right or wrong if they actually did do the things we think they "should" do, but that doesn't make the initial assertions invalid. For instance, I stand by my comment that parachutes should be free-update material, not paid-DLC material. Not must but should. Because, in my opinion, making people pay for them is bad form. Not necessarily bad for business, but bad form, in the same way microtransactions, while possibly good for business, would be bad form. I think paying for Kerbal survivability crosses the line from "additional content" to "pay-to-win," and if that were the only thing in the DLC I almost certainly wouldn't be buying it. Fortunately that is far from the only thing in the DLC, so it doesn't really color my enthusiasm for the expansion as a whole (I'm really looking forward to new Soviet-style parts!), but it is still something I notice and dislike.

Fair enough. All the more reason to make sure this DLC is really good and worth paying for: if the competition is free, it'll never compete on price, it has to compete on quality.

Personally I have no problem with paid DLC, and a nice Soviet parts set and a new spacesuit (the missions don't hugely interest me, but I might get more excited when I actually see them) sounds like a perfectly reasonable addition to the game for somewhere around $10. Just make sure there's a good two-kerman pod in there somewhere. (That said, I do think including Kerbal parachutes in a paid DLC is a bit cheesy. Those should go into the stock game. New parts are one thing, but people shouldn't have to pay extra for their Kerbals to survive crashes.) I guess I'm in the "Squad needs to keep their business running somehow, better DLC that adds content than pointless merchandising" camp, not the "DLC is evil" camp. As long as we don't end up with microtransactions. Those are evil.

I don't know if this is helpful or not (haven't tried this mod yet, although I'm thinking about it for later in my career save), but in my experience that option in stock doesn't work properly. Renaming the asteroid from the right click menu changes its name in the right click menu, and changes the name of samples taken from it--but doesn't change how it shows up in map view or the tracking station. To do that I have to rename it from the tracking station (as I would a piece of debris that has no command module). I don't know if this is intentional, a stock bug, or a mod-related issue; it's not enough of a problem for me to be bothered trying to fix it, but it might explain why people are having issues with this mod. Or maybe people just don't know about stock vessel-renaming options. They are pretty well-hidden, after all.

Boring stuff: TL;DR: Trajectories, Persistent Rotation, getting bored of stock stupidity, looking for suggestions on planet mods. Starbus Valerie on Minmus. Starbus S-200 Dauntless and Lucidity 2: a new SSTO. Brevity II: munar sightseeing. Starbus S-300 Valiance: a new heavy shuttlecraft. Crew rotations. Daring 3 arrival at Dres.

Thanks! I haven't actually posted a complete mod list in a while. The main visual mods are SVE, SVT, Engine Lighting, Real Plume Stock, Texture Replacer, Planetshine, and Distant Object Enhancement. The post-processing effects are Gem FX, which I usually don't have running while actually playing (it's kind of distracting) but toggle on for screenshots; I think it gives them a nice photographic sort of feel.

@eloquentJane So I gave CCC/FTP a try & it looks like they work fine as long as I delete the fuel switch config from CCC. I'm going to uninstall them again for now, since I'd like to keep everything, including the parts' appearances, stock until I've achieved my original goal, but I'll definitely put them back once I get to that point. Thanks again for the suggestion!

Normally all you have to do is set it to "disabled" in the right-click menu (this can be done in flight or in the VAB/SPH). It might require Advanced Tweakables to be active in the settings menu, I don't remember. However, anything with wheels on it has forced autostruts which can't be disabled; I believe this is a workaround for a bug with the Unity wheel system KSP uses currently.

Yep, I just now noticed that in the FTP readme. I'm going to (temporarily) install them now and see what happens.

Ah, in that case maybe it will still be an option. And texture switching shouldn't be an issue (I already have Firespitter.dll for texture switching on Nebula Decals), it's only fuel switching I'm concerned about. I will investigate.

Ah, I forgot about that. I kind of dislike the idea of existing spacecraft inexplicably changing appearance, so maybe I'll just have to save FTP/CCC for my next career. I will investigate at some point though; there may be a way around that.

I believe the tank-refilling thing is a problem common to all fuel-switching mods (I first encountered it with Stock Fuel Switch when I tried to install it in my old 1.0.2 save), although I will definitely investigate. I think if I really wanted to install one, I could edit the save file to fix the fuel levels in a few active vehicles, and just ignore the issue for old ones no longer in use. It's not a prohibitive issue, just an annoying one. PS. Although it's possible that I could remove fuel switch configs for stock tankage. That might prevent it messing with existing vessels, and I could just use the new tanks on new ones.

Good suggestions, I may go for both of those. I do like @NecroBones's color switching options, especially on the large SpaceY tankage. One issue though is Interstellar Fuel Switch, which has the unfortunate side effect of magically refilling all fuel tanks on existing spacecraft when installed mid-game. I may be able to find a workaround for that, however.

It's actually not as bad as it looks, as evidenced by fact that the rocket didn't need tail fins. The Brillig III/Defiance shuttlepod (which does need fins) is actually quite a lot less aerodynamic. Plus the ascent profile I've been using--straight up till 100 m/s, tilt ten or fifteen degrees downrange, then hold prograde the rest of the way--allows me to get away with practically anything, since the rocket spends almost the entire ascent at zero AoA and therefore never gets much of a chance to flip.

Boring stuff: TL;DR: KER. Daring 3 underway. Bravado 5 return from Gilly. Brevity II: anomaly hunting on the Mun. Exploration of Duna. Daring 2: another test flight. Daring 3: mission to nowhere Dres and a new launch vehicle.

Nobody's refusing to understand anything. It's an abstraction to represent increased skill. I get it. I just think it's an overly simplistic abstraction that fails to represent increased skill in a sensible way. And this doesn't have to be a binary right/wrong thing (or a nasty argument in which both sides write off the other as being obstinate for the sake of it). There are plenty of ways in which pilots could be made more useful, a number of which have been suggested in this discussion. Personally I like the improved RCS/reaction wheel option, which is also an abstraction to represent increased skill but which (in my opinion) would have a nicer, more balanced gameplay effect. And as @razark says, as long as pilot skill ISP modifiers were implemented as a penalty rather than a bonus, and could be switched off in difficulty options, I wouldn't be too bothered about it, even if I'd have preferred a different option.

Gains in efficiency of spacecraft come from skill in navigation, not the actual operation of the engine. In fact that's largely true of racing drivers as well; sticking as close as possible to an ideal racing line is one of the most important factors to getting the most out of your car. But in KSP, as in racing games, navigation is something the player is doing, not the kerbals. Trying to abstract it onto a kerbal skill just seems like a hack--no different than if "leveling up" in a racing sim inexplicably gave every car you drive more horsepower. Another way of looking at it: scientist and engineer bonuses make life easier, but there's no mission in the game that requires a level 5 engineer or scientist and simply cannot be done otherwise. If pilots got an engine ISP bonus, you get a situation where a mission on close delta-v margins might be not just slightly trickier or riskier but actually impossible without a level 5 pilot. To my mind, that's not the way it should be--skill bonuses should make missions more convenient, but not determine whether they're possible or impossible.

Personally I don't like the idea of pilot skill increasing engine ISP, even as an abstraction. I could, however, get behind pilots improving RCS ISP and/or reaction wheel torque (as an abstraction of the idea that a better pilot can maneuver the spacecraft more effectively/efficiently). That would be just as easy to implement and make more gameplay sense; it doesn't really enable missions that couldn't be done otherwise, as an engine ISP bonus would, but it does provide a reasonable incentive to send high-level pilots on missions--they would make the spacecraft easier to, you know, pilot. I could also go for auto maneuver node execution, but something tells me autopilot of any kind would be too "un-kerbal" for Squad. Although the whole "keeping silly aspects of the game because it's the 'kerbal' thing to do" attitude came from the old dev team, maybe the new one is a little less attached to it. With 1.2 autostruts, they finally managed to get past noodle rocket syndrome, so maybe such un-kerbal concepts as delta-v readouts and autopilot functions aren't completely out of the question.

Not sure if Squad has gotten the message about putting more info in the KSP Weekly, or if there's just more info to put now that they're closer to release, but either way it's a nice change. Looking forward to 1.3.

I did this back in 0.90, when I was playing for the first time. I'd generally get anywhere from just into Kerbin orbit to exploring the Mun, Minmus, and preliminary probes to other planets before switching to a new mod configuration and starting over. I probably went through a dozen or so career saves without ever really getting very far. For some reason, I stopped doing it with my 1.0.2 career. Maybe it was because that was the first time I went interplanetary with kerbals, but that one sort of "stuck" where previous ones hadn't. I kept playing it through the rest of 1.0.x and 1.1.x, and had to absolutely force myself to find a stopping place so I could start a new career in 1.2. That one is still going, and although I already have some thoughts about the next one, I don't expect to actually start over for quite a while yet.

One option to avoid cluttering up the UI would be to have an "airplane mode" (like we have "docking mode" now) where all the usual SAS options are replaced with horizon-relative ones like you'd have in a plane. I forget if it's been mentioned already, but a "hold vertical" mode (or better yet, a "kill horizontal velocity" mode) would be useful as well, especially for landers and VTOLs. And just in case it isn't already obvious, I support this.