Tarmenius

Ok, fair enough. Just bear in mind that even if it's meant for use with one other part, doesn't mean it's only possible use is with that other part. For the airlock, I think a bell shape (instead of the current cone) may still be suitable for re-entry and provide enough length to stow helmets. Thoughts?

I think the inflatable airlock is a great idea, as long as the pod is made long enough for us to imagine that their helmets could be stored somewhere. As for the "one use" argument, any adapter has only one use: Adapting from one size to another. If you're referring to limited use, what about the antennas? They're only used for "one thing" (at the moment). A very necessary thing, of course, but it's still just one. Or how about solar panels? They only do "one thing." But perhaps I'm not understanding the nature of that argument. Feel free to explain if I've got it wrong.

Sorry, allow me to clarify: What we're wanting is a command part which is a size category smaller than 2.5m and which can hold 2 Kerbals. I've been trying to keep up with the news but I may have missed something. Will the new Mk1 Cockpit seat 2 Kerbals? Or does the Mk1 Crew Cabin provide Reaction Wheel torque and allow the ship to be controlled? If either of those is a "yes" then the new plane parts definitely fill that need for me. Add a heatshield and it should be perfectly capable of re-entry without breaking any kind of logical consistency. But that's a whole other discussion.

What we're wanting is something which is a size category smaller than 2.5m and which can hold 2 Kerbals, so this suggestion doesn't address the issue. There's already a 2-Kerbal, 2.5m pod. It's the lander can. Whether that should be suitable for re-entry is another discussion entirely.

I agree that this is probably the solution that stands the best chance of being implemented. Though personally, I'd prefer the 1.25m series be increased to 1.7 or 1.8m instead. Ever since EVA was introduced, I've always felt it was a little thin anyway.

If their helmets could be slimmed down a little (and maybe shortened slightly), they'd totally fit: That's an overturned Mk1 Command Pod, by the way...

I think the "gap" people are referring to can be explained as follows: 1.25 +1.25 = 2.5 (+100%) 2.50 +1.25 = 3.75 (+50%) So, the relationship between small and medium is greater than the relationship between medium and large. This difference creates the sense that there is some unused "space" in the scaling of parts. Apologies if I've misread. As for the crew capacity issue, I would definitely love to see a 2-Kerbal pod in the smallest standard part size. Sadly, they just wouldn't fit within a 1.25m pod unless one was behind the other (maybe also slightly higher, as Kerbals are very short when seated?). Of course, SQUAD could just decide to do it anyway and leave us laughing about the way Kerbals magically shrink when they enter. That could be fun, too. Another alternative would be to change all 1.25m parts into something large enough to seat 2 helmeted Kerbals side-by-side (would 1.7m do it?). No need to add a whole new part category. I personally think three standard and 1 non-standard (0.625m) is a good balance.

Yeah, the earliest edge of the dark-blue area. I probably should have adjusted all of them similarly, but oh well... The windows are pretty wide anyway.

Remember that windows only represent times when the transfer can be done with minimal fuel costs, and as such they have no hard "start date" and "end date." But, according to the alexmoon launch window planner (linked above by mhoram), the order is as follows (in Kerbin time): Duna: Year 1 Day 216 Moho: Year 1 Day 253 Dres: Year 1 Day 340 Eve: Year 2 Day 117 Jool: Year 2 Day 230 Eeloo: Year 2 Day 250 These "windows" usually last several days (in a couple cases more than a week), so launching on exactly the listed days isn't really necessary.

I recently made a first attempt at a small re-entry glider. Well, first attempt post-1.0 anyway. I brought it down from 100km in a descent path that was probably about 20 degrees or so during the upper atmosphere and at a fairly dramatic AoA. Almost "bounced" right back into space. Next time, I'll be taking a page from NASA's shuttle and performing S-turns instead.

I wasn't actually defending instantaneous light. My only point was that the simplification is a low-cost design choice, unlike the choice to disable probes completely when they lose communication with Kerbin. Personally, if they decided to make light (and therefore signals) travel the appropriate speed, I don't know how I'd feel about it. At interplanetary scales, light feels a lot slower than you might think. And now I'm curious... which mod models this?

Ok, so maybe "unreasonable" was the wrong choice of words Still, I imagine that would frustrate more players than it would please. And while it's no more realistic than instant-light-travel, most people don't think about the speed of light in their daily lives (though many of us here do, I'm sure). So the fact that it's instantaneous likely doesn't even register to most players. That unrealistic "game simplification" is much less likely to be noticed in the first place than the fact that people's probes don't work at all sometimes. Glad to hear that. I'm looking forward to the feature regardless, and it'll be interesting to see how you implement it.

From what I understand based on the article (and someone correct me if I'm wrong here), the Relay Network feature will affect 2 Game Systems: probe control and science transmission. For probe control, I see only 3 ways to handle occlusion: 1) The player loses all control of the probe; 2) The player retains all control of the probe; 3) The player retains some control of the probe. #1 is unreasonable (and unrealistic), #2 means the feature will only affect 1 Game System, making #3 the likely solution. To implement this they could say attitude control is removed but throttle control remains (or vice versa), but that doesn't make much logical sense. So, the most reasonable solution seems to be some form of "programming" of the probe. Allowing it to execute maneuver nodes is likely the best way as tater most recently mentioned, and for the reasons he gave. But given that the current probe control mechanics limit which can be used for SAS functions, it could end up that only some probes can be "programmed" at all. If that's the case, I hope it's only the very early one or two probe cores which lack that functionality. For science transmissions, the solution's probably obvious to anyone: No transmissions without line of sight to Kerbin or another probe which itself has line of sight to Kerbin. Care to elaborate on those other ways? I'm having a hard time imagining what they are.

Glad I could help! And most people around here aren't troubled by even the most frequently asked questions, so don't even worry. At worst, someone might point you toward an answer and roll their eyes, but this is generally a very helpful place.