Deutherius

Harmonious Anti-Metastasizing Berry (with) Unlimited Range (and) Generally Ecstatic Responses MOISTURE

Lord Eigenhower never ceased bringing caramel yams. vrldztse

Covert Operative (with) Neverending Flair (and) Upbeat Stories (of) Enhanced Destruction ANTAGONIST

I almost got Bill to slam dunk the ball through a basket, but the positioning is really hard on Kerbin. Mind if I do it somewhere else? Or I could just send it through the Mun arch and call it a goal?

Very energetic bobcat cornered your dastardly grandma. jrbewpfe

Mating-Observing Robot (for) Nigh Invulnerable Nightmare Gazelles AUTOMATON

It could be argued that no other fuel holding stock part can make such a simple, yet terrific beach ball. Yes, it would be possible with xenon too, but it just wouldn't be the same. Xenon doesn't lead itself to such explosive plays. Conside me part of the Save the ROUND-8 movement.

So, we've got a Base-in-a-box, Space-station-in-a-box, and now an SSTO-in-a-box. What's next?

It does sync. And a funny twist, the "Landing Gear" function itself is an action group. It is located in the same tab as custom action groups (under the name "Gear"). The game defaultly places every landing gear in that action group and you are free to remove any gears from there, or add any parts in there. One important thing is that all of the non-custom action groups behave differently, regardless of the action of the part itself (e.g. the landing gear has a "retract/deploy" action in the gear action group, but gets synced with the group). These "syncs" work only on toggle actions - if you put a "turn on" action in there, the action group will simply trigger the part's action regardless of the "sync state" (e.g. put a "Turn light on" action into the gear category, launch - the gear says "On", the light is off - press G, the gear group goes "off", light goes on at the same time without waiting for sync). Quick overview of what I've tested and found out: Stage: works the same way as custom action groups (triggers part action without any changes) Gear: starts on, syncs every toggle action in the group to the same state Light: works the same way as Gear, but starts off RCS: same as Light SAS: same as Light, BUT has an optional "pulse" mode - can be turned on by the F key, and will stay on until you stop pressing the key Brakes: same as SAS - but this one can get more use as brakes are (at least in stock) only relevant with wheels and while on the ground. You can easily set up retro engines that will fire only when you hold the B key - which is usefull! Also, unlike the SAS, you can take out the brakes of wheels from here (so it does only what you want it to) <edit>The same with RCS - that stays linked to its primary function in the same way that SAS does </edit> Abort: Same as Light While this might be kinda unintuitive, it is also a very powerful tool the designer can use to fine tune his craft's handling keys. Also remember that you can use one part's action in multiple action groups, creating a whole new mess level of depth!

No. You can only differentiate between provided types, and "crewed" or "uncrewed" are not part of that. You can, however, change a type of any vessel to anything else - you can work around this issue by changing the type of your currently uncrewed vessels to "probe", or something you rarely use, and filtering that. Changing the vessel type each time a kerbal enters/leaves a capsule sounds tedious, though. No idea about mods that would do this, sorry.

Eccentricity of your orbit will make a difference, it is however something you will have little control over, as it is (in a simple Hohmann transfer) determined by your origin and destination. If you start on Moho and go for Duna (and place Ap at Duna's orbit), you orbit will be much more eccentric than if you start on Kerbin, your velocity at Ap will be slower, and therefore Duna will be moving faster relative to you, demanding a harder circularization burn and/or more intense aerobraking. If you overshoot the Ap, you might be moving faster relative to Duna at randezvous, but in a different direction - the difference in Kerbol-relative speeds might be better for circularization, but the difference in velocities might not. That's where the gravity sling comes in along with the atmo to help. I'll be the first one to admit that I have not studied orbital mechanics in depth, though, so I'm just stating what feels intuitive to me based on what little I know from playing KSP... It's entirely possible I got it wrong. If you want to be sure, it shouldn't be too hard to fire up a sandbox save, turn on infinite fuel and test it

I think that for atmospheric bodies it doesn't matter, as you'll be aerobraking anyways (and the planet's atmosphere will essentially grab you to go as fast as the celestial body does). For bodies without atmosphere, it will be largely dependent on a few factors - how elliptical your orbit is, how much is your Ap overshooting the target body's orbit and how massive is the target body. - More eccentric orbit will need more dV to circularize (related mainly to departure and target bodies - Moho -> Eeloo will take more to circularize than Duna -> Eeloo) - The more you overshoot the target orbit with your Ap, the more velocity you will have to redirect (essentially burn radial out instead of prograde) at the encounter, which will take more dV, but - The more massive the target is, the more gravity it has and is able to help you via a gravity assist (you just have to pick the right direction at which to arrive, behind or before the body to either accelerate or brake) Best case scenario, the way I see it, would be to position your Ap as close to the target orbit as possible, and let its atmo and/or gravity help. Please note that I may or may not have no idea what I'm talking about It just kinda makes sense to me - it's more efficient to circularize at Ap than it is before/after Ap when doing a Hohmann transfer, so the same principle should apply here as well (it's still a Hohmann, just with a celestial body at the end)... Right? EDIT: As to the two presented pictures, I think the second one would be more efficient, but both would be suboptimal. Best result here (as for ease of circularization) would be the classic free return "loop" around the Mun - that should mean arriving slightly ahead of the Mun with Ap slightly above the Mun's orbit.

Maybe you could support your claims of the properly structured bug reports that you made with some links?

The mountain range just west of KSC is not sufficient?

We have lights... That is beautiful. *salutes the ROUND-8 memorial*

Well, no, they don't, unless you get things wrong and clip the nozzles into other parts completely. That can cause the other parts to overheat and explode. But I meant the part after 20 minutes, where he demonstrates a real, viable building technique.

Well, there are ways to lift crazy things even now... Redirection to Whackjob's starting youtube series, if I may. Not sure if it's what you need, but many crazy things should be expected indeed. I personally like to use the TT-70 most, mainly because of the extra clearance they provide. Haha, banana Anyway, nothing prevents you from putting the elongated structural parts on the payload stage and strutting down to the lifter stage from there. They can even be made disposable by radial decouplers. (Please note that the upcoming KSP 1.0 aerodynamics overhaul will likely end that as well)

Might be unrelated, but have you tried using a bigger decoupler? I don't think that the TR-2V is designed to handle 42 tons of hanging mass Also, that video is very old, I seem to recall that thrust plates are obsolete now, at least for that purpose - the radial decouplers + few struts are more than enough to handle big boosters.

Not all that unique - a simple spaceplane with a payload consisting of a legged lander. Or a spaceplane with landing struts on its aft (for ease of landing on atmosphereless bodies). I'm sure it has been done many times. I don't think it's possible to solve this problem generally with any detection algorithm - you simply cannot predict what the player will intend to do with his landing gear/strut sets, and there will always be designs that won't conform. That's why we have action groups, though.

Does anyone have actual numbers? I would assume that 8 of the 9 engines (just the outer gimballed ones - or maybe just 4 engines?) are burning at 70 % (the minimum throttle of the Merlin D1), which gives me thrust, but I have no idea about the almost-dry mass of the stage.

It's the other way around, as Starhawk has stated - the game believes your landing gear should start in the "deployed" state, and will light up the gear icon regardless of the actual landing gear/strut state.

Rapidly enthralling visions called Juan "Communist Usurper". pskbfeu

I build me one of those too... I called it DERP - Donut-shaped Emergency Rocket Pod Maybe I can rebuild it to have an Ion engine... Nah, 48-7S is just too good. RIP ROUND-8, you will forever live on in our memories... ...and modded KSP.

15 0char

That largely depends on when it would happen and how the flight computer would deal with it (I would assume they have some routines programmed just for this). Maybe the Merlin cluster's gimbal would be enough? Maybe one engine could throttle/shutdown to compensate for the drag? Maybe the legs could get jettisoned, preventing the barge landing but also a complete failure? Or maybe it would just tear the rocket apart. *shrug*