AHHans

Gravity and steering losses (in dV, not tonnes of fuel burned) are independent of the size of the rocket. A small and a large rocket with the same TWR, following the same trajectory will need exactly the same dV. The relative amount of drag also doesn't really depend on the size of the rocket, a well built rocket will have very little drag during a normal gravity turn, i.e. when pointing directly into the wind (= prograde in surface mode). What makes a difference for me is that the stuff that I send up get bigger and bigger in the late game and look less and less like a streamlined pointy cylinder. At some point they don't even fit inside a fairing anymore. Such a payload has large drag, even compared to its mass.

Interesting study @RizzoTheRat. I take away from this two things: one is that not turning enough (and early enough) will induce the greatest losses (I guess mostly steering losses during the circularization). And the other is that the your total dV costs fall into a range of 100 m/s, less than 5% of the >3000 m/s that you need to get to orbit. So as long as you keep a somewhat reasonable gravity turn you won't loose too much dV to really worry about. Indeed! My personal rule of thumb is (has been already before your study) that a TWR larger than 2 is wasteful. But that can all be trumped by expediency: it is much easier to just stick one of my standard lifter subassemblies below a payload than fine-tuning it to the task at hand. - Or, now in the late game more likely: stick an oversized lifter onto my payload and go for a high trajectory, than trying to streamline the payload.

Waaahhh! Maybe I should read more often, it actually says so in the description in the tracking station: Also: So my guess is, that the size of an asteroid depends a) mostly on the class, and b) on the exact "seed" that determines its shape, but not really on the actual mass that it has. So I guess that a 200 t class-D asteroid can actually be slightly smaller than a 600 t class-D asteroid, but an 800 t class-D asteroid will always be significantly smaller than an 800 t class-E asteroid. (I now actually bothered to measure my craft: it can accommodate asteroids of about 11 m diameter, so no chance to fit a class-D in there...)

Well, O.K. Maybe it's something else. I used the definition of "lift" and "drag" that is also used here: https://en.wikipedia.org/wiki/Aerodynamic_force And here: https://en.wikipedia.org/wiki/Lift-to-drag_ratio it says that e.g. the space shuttle had a lift to drag ratio of ~1 at hypersonic speeds and ~4.5 at low speeds.

O.K. Well, yes and no. For aircraft in KSP I identified two general regimes: low&slow and high&fast. At low-ish speeds (say less than mach 2.5) and low-ish elevations (less than 10 - 20 km) the aerodynamic forces (on most craft, I'm sure you could create an exception to the rule) are dominated by lift. At high elevations the air is too thin to generate significant lift, but at high (e.g. near orbital) speeds the drag is still significant. So your craft is aerodynamically stable falling "tail forwards" in the high&fast regime, but in the low&slow regime the airbrakes generate less drag than the winglets at the tail generate lift, so it flips (at least when I tried) and falls nose forwards. [*more testing*] The "SAS induced roll" is because you have way too much roll control authority when the winglets generate significant lift. Not only are all winglets ideally placed to affect roll, but also you have little moment of inertia along the longitudinal axis. Combine that with the fact that SAS doesn't try to minimize the speed of roll, but tries to keep a certain angle of roll. So when SAS tries to do a small correction to roll, it oversteers by a large amount. Then either because due to a bug in the implementation (number overflow?) or in the design of the SAS control algorithm it keeps oversteering more and more. If you disable roll control on the winglets, then this doesn't happen, and SAS manages to keep the craft steady ... until it wants to flip.

So you manage to drop the Go-Op module to the ground, but it doesn't deploy (the goo-cylinder and the camera remain inside their slots and don't move out, like on the screenshot you posted), correct? Does the experiment control unit deploy? Do you have enough power to operate the modules? Can you post a screenshot with the right-click windows of all the dropped (deployed?) modules (including the solar panel) open?

Well, the list of non-stock parts in the craft file is pretty long, my stock KSP refuses to load the craft.

That's kind of what I thought after looking at the savefile(s). Well, I guess I'll have to settle for a smaller class... (And use another craft for that one contract.)

Which version of the game are you using? As far as I can tell, there is no keyboard shortcut for switching between the VAB and the SPH in my version of the game (KSP 1.8.1 on Linux). And when I do switch between the VAB and the SPH by clicking on the button then the current vessel doesn't get deleted.

Don't worry, we've all been there! I just noticed that this was your first post here, so: Welcome to the Forums! We are a fairly friendly bunch here, so don't hesitate to ask more questions.

Does anyone know how the size / radius of asteroids are determined? Does this change with the mass of the asteroid or is this fixed with the class? (In other words: if a 600 t class-D asteroid doesn't fit into a certain space, does a 200 t class-D asteroid have a chance of fitting in there?

Have you tried giving it a kick? I only got these error messages when already deployed science stations are loaded back into the physics (because I got close to them again), but they usually sorted themselves out again on their own. Do you get this message while the part is still held by the Kerbal, or after it got dropped to the ground and while it is trying to unfold? In both cases, try moving the parts a bit around where these isn't anything in the way. If it is still held by the Kerbal then try moving the Kerbal around, maybe he was standing on something (another, already dropped, part?) and thus technically not standing on the Mun itself.

Have you tried activating "same vessel interactions" on the two parts that are supposed to bump into each other?

The green lines in the KAL track editor are for continuous values like a servo's traget position, a rotor's max RPM, a piston,s target extension, or so. These values can (and should?) change smoothly over time. The blue lines - and more importantly the dots on these lines - are for triggering "instantaneous" events, like toggling motor power, (un-)locking a servo lock, toggling the "open / closed" state of bay doors, etc. Those events get triggered, whenever the play position of the KAL reaches a marker dot on the corresponding blue line. You can add a marker dot with the "+" symbol in the middle of the row with the buttons in the track editor, and then move it around with the mouse or enter the exact time in the field at the bottom right. In other words: you get a green line for options that you can control with an axis action group and a blue line for options that you can control with a "classic" action group.

It actually says so in the first image (Steam client screenshot) that is linked in the tread you referenced: version 1.0.5 (And, yes, I just checked that's still the oldest version available on Steam.) As to downloading versions before that: I have no idea if - and if so, how - this can be done. Sorry.

Let's see: 34 days and 8 mins and 34 days and 3 mins is a maximum difference of 5 min 34 days and 5 mins are: 34 (days) * 6 (hours/day) * 60 (min/hour) + 5 (min) = 12245 min for one orbit deviation per orbit: 5 min / 12245 min = ca. 0.00041 one tenth deviation in: 0.1 / 0.00041 = 243.9 orbits in time units: 243.9 (orbits) = 243.9 (orbits) * 34 (days/orbit) = 8292.6 (days) / ca. 400 (days/year) = ca. 20 years Yes, that last line is a rough estimate. A Kerbin year isn't exactly 400 days long, your orbits aren't exactly 34 days long, yada, yada, yada. Who cares? I probably could, but I'm not going to!

Ah, O.K. That means it'll take them about 20 years to move one tenth out of (relative-)position. I would still try to correct that, but if that's fine for you then just leave it.

Well, what fraction of the orbital period are those +- 5 min? How many orbits does it take to completely mess up the formation? In other words: I'd change the orbits so that they have the same orbital period down to as good as possible (e.g. one second?). (It doesn't matter so much if they have this period with identical AP and PE: as long as the period is identical they'll keep their relative positions.) You may want to lower the thrust limit of the engines on the satellites to do that.

Errr... the correct equation is: delta-V = Isp * 9.81 * ln(mass_at_start / mass_at_end) See: Tsiolkovsky rocket equation on Wikipedia.

There is also an informative wiki entry about SAS, that includes a table which probe cores and pilot levels enable which SAS abilities.

In KSP there is also another variant of hot-staging that isn't used in real life for reasons that should be obvious. And this is to fire an upper stage while having the lower stage directly connected to it without a decoupler. That way the flames from the upper stage will heat the lower stage until that explodes and you finally get rid of the lower stage. Thus you can have a multi-stage rocket without having decoupler technology.

Ah, O.K. Usually when people call something a bi-elliptic something they mean a certain form of: Bi-elliptic transfer maneuver. I usually aerobrake at Kerbin, because I'm returning with only a capsule anyhow. But even when I return with a craft that I want to keep I don't bother with two transfer burns. An now that I think about it, it seems unlikely to me that you can save significant dV by doing a second transfer burn: you don't get any benefit from the Oberth effect around Kerbin or Duna (or wherever you go) for that second burn. Do you have an example where you save dV by doing a second transfer burn? Also 5 km/s for going from Duna orbit to LKO seems a bit excessive. [.... *boot up KSP*, *open sandbox*, *time-warp 500 days*, *cheat to orbit* ...] Hmmm... O.K. You need a 3 km/s burn to capture into LKO if you don't do any aerobraking. But the initial 2 km/s burn to get to Kerbin (and a small plane change & correction burn halfway in) is essentially what I regularly do, with the difference that I then slam the capsule into Kerbins atmosphere and make fun of Bill and Bob for passing out. (Valentina is a steely-eyed rocket lady and doesn't mind a dozen g or so. )

O.K. But even then the way that this part is reported is strange. You could check in the save-file if the semi-major-axis (SMA) of the orbit is smaller than the radius of your Moon.

I think with the free quality of life improvements, the big switch to a new version of unity, and the new DLC(s) this award is well earned!

Indeed. Are you using any mods that might interfere with the selection of parts that the rescuee is in, or with the contracts itself? Is there an option to track "Cridson's Debris" in the tracking station?