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.

Turbojet SSTOs were definitely doable in 1.0.2. In fact, all you really needed was a single Whiplash: Take a look at these examples They key is to build as much speed as you can through at 10-12km. The ascent profile looks pretty different from pre-1.0 techniques.

I have stories like this as well and remember them fondly, as you do. But mine only exist within Kerbin's SOI. When KSP had only Kerbin and Mun, the "trial-and-error" mentality totally worked well as a design choice. Even more so when there was no persistence: Flights never lasted longer than a single play session anyway, so simply ending a mission was common practice. But this is no longer the case. Ending a mission now destroys the crew, flights last through several play sessions and represent many more hours of player investment, and travelling beyond Kerbin's SOI involve more planning and effort despite the fact that a Mun-capable rocket can reach Duna. So, from where I sit, the original plan of "figuring everything out yourself" really needed to be re-evaluated once the level of sophistication and scale grew beyond a certain point. I think the data SQUAD has which indicates most players don't leave Kerbin's SOI should have been the first hint that something wasn't working as they intended. A core game feature that goes largely unused highlights a major fault in design. One of those, in my view, is the lack of information and tools provided to the player caused specifically by the "trial-and-error" mentality. Take a hypothetical mission to Vall for instance. Say it runs out of fuel in Jool orbit before getting an encounter with Vall. To mount a rescue mission, I have to re-design the craft, repeat the previous mission events and hope I tweaked it correctly. That's a lot of effort for potentially no reward. It's for similar reasons that classic-style western RPGs have the adage "Save early, save often." Nobody wants to just lose a few hours of advancement in the game, and so most players decide it's not worth the risk to leave Kerbin. That a dv readout is coming to KSP at all is a great thing. And I can understand the choice to bind it to Kerbal skills, though I disagree with it. Hiding this kind of information behind "gates" is bad game design in my book. As a designer, you ask yourself "Do I want the player to have this item/information?" If the answer is "Yes," you give it to them. If the answer is "Yes, but the player must work for it," then the mechanic you design must be interesting enough for the player to enjoy "earning" it. Making players grind for something you want them to have anyway is no way to build an engaging experience.

The conjunction of Jupiter and Venus is supposed to occur on July 1, so perhaps Jool, Eve and Duna will be visible from Kerbin?

I've been following this thread from the beginning, and I think I may have a way to clarify what's being misunderstood here. With the addition of new parts, the possibility space for craft design has been expanded (a wider range of part combinations exist). The possibility space for successful designs is much smaller, and the new aerodynamic and heating models have made it smaller still. This is good for people who favor Realism over Gameplay (when the choice needs to be made) because it more closely mimics our reality in that we must carefully design our spacecraft. However, consider that this extra time and effort is spent just to achieve the same goal as before: Getting to and from orbit. Increased effort for the same result is the very thing HarvestR was trying to avoid when he decided Kerbin should be much smaller than Earth. Thus, the new systems have shifted KSP a bit toward the "Simulation" side (for lack of a better term) and for people who favor Gameplay over Realism, this is a negative change. So, Vanamonde's issue here (if I've been reading correctly), is a reflection of that shift. Hopefully there exists some solution that will reduce the time and effort aspect without sacrificing the Realism of the game's calculations. Honestly, I think this also highlights the fact that the physics simulations being run by the game are far more sophisticated than the tools available to the player. This is the game design fault I was referring to much earlier.

I'd say the way to tackle Action Groups would be a dialogue wheel: Hold a button, the game pauses and a wheel is displayed, divided into segments for the various Action Groups, or other common commands that don't need to be used immediately. Staging wouldn't be there, for example, but Toggle Solar Panels could.

Why would anyone expect it to not be able to reenter in one piece? Sure we all know that reentry heating is a thing, but how is anyone supposed to know beforehand that their lander is going to flip over and potentially roast on return to Kerbin? With the current Science system, players are encouraged to bring back the instruments (and other parts, thanks to Recovery). Yet the aerodynamic and heating models make that difficult to accomplish and the game gives us no tools to predict that difficulty. The solution of "Move all Science to the pod and ditch the equipment before reentry" is not something a first-time-to-the-Mun player is likely to think of naturally and they won't realize their mistake until it's too late. I think this highlights a fault in game design and Vanamonde is right to point it out. Sadly, I don't have any good solutions. As I see it, either include some tools for the player to make sense of the atmosphere and heating models, or simplify the models themselves. Both would require significant amounts of work and each would displease a segment of the playerbase.

From what I understand, it piles up in the engine itself. Or, it would in real life; I doubt it's actually modeled that way in KSP. Come to think of it, closing the intakes should probably generate more drag as you could imagine the air entering the intake only to hit a flat surface inside.

Astonishing is definitely the word for this! Way to go Falconer!

redsh: Very cool high-wing design! I especially like those LV-909 pods underneath. --- This talk of turbojet boosters has given me another idea...

Very clever! I never thought to subdivide the tanks to get more precise control over fuel amounts. Also, from what I understand (someone feel free to correct me) the Shock Cone generates less drag so you could probably squeeze a little more dv out of the design that way.

Wanderfound: I really like what you did with the Oscar-Bs on your Kerbobee! The whole craft has a sort of MiG vibe to it, too. Awesome. I'd really like to see how much mass the Turbojet can push around with FAR, to see what difference there is in practical terms between the two aero systems.