SZDarkhack

I was about to ask what a bunch of anime chicks have to do with KSP, then the rest of the image finally registered in my brain

I'm not an expert on DRE or anything, but you might want to come in a bit more steeply. I think the problem here is that, although the shield is heating up, there is not enough density to really get the ablation going (refer to Nathan's post above). Try a perigee of around 35k-45k from LEO. Around that value you get a maximum of around 8G deceleration (which the probe should be able to handle comfortably, even a manned capsule is fine with it). For a more technical explanation of the issue, an ablative heatshield isn't supposed to insulate the craft from the heat, but rather remove heat via ablation. If the ablation doesn't happen fast enough to remove the heat, it will flow through the shield and damage it (and the craft).

I'm familiar with reverb settings (from music experience) but It's easier to understand them by playing with them and seeing what they do. If you do need some clarification though, feel free to ask.

You are correct, you cannot hear the boom inside the ship (and the addon models that properly in the IVA views). The exterior views are from the camera's perspective, so if you move the camera into the sonic boom then you can hear it.

Within the KSP installation directory it is: GameData/BoulderCo/common.cfg

Yeap, that's pretty much it. I certainly don't mind you using the code, that's why I shared it in the first place Also, I apologize for the code being completely uncommented, I'll make sure to be much nicer to anyone else working on it and properly explain confusing parts (for instance that volume lerp is pretty cryptic if you don't know what's happening outside the cone, which is half a page later ). I'm glad that you found it useful anyway. The changes (from a quick source read) look very nice by the way

Hmmm... I haven't been to Laythe with RSS (and I haven't had a chance to even see v5 if that's what you're using) so I don't know what's a normal orbital speed around it. You might be able to reduce your encounter velocity a bit. Make sure that you're encountering it in a prograde direction and from a low inclination. The closer you are to a tangential intercept the better. You might also be able to do something else here. Don't worry too much about getting captured in Laythe orbit in one shot, but try using its atmosphere to get a capture around its parent body (depending on version either Jool or Dres (Saturn)). Go out to apoapsis and use minimal fuel to get another encounter. Keep doing this and slowing down incrementally at each pass. This will obviously take a lot longer, but eventually you should have a more manageable encounter velocity. If there are other moons (so at Jool), you could also get a beneficial slingshot from one of them. NASA does this sort of thing all the time, for instance in the Cassini mission. Other than that you can try turning the vessel to its side while you're at the high part of the atmosphere to get a bit more drag, just make sure to bring it back to a stable orientation before the aerodynamic forces become too much to handle.

The Martian atmosphere is very thin, so it's not that good for aerobraking, especially for ballistic (i.e. non-winged) vessels. Try doing multiple passes through it. Get a capture with your first pass (any capture, it doesn't matter how high the apoapsis is) and loop around a few times passing through the atmosphere until the orbit eventually comes down.

Again, this is a *wrong* indication. There IS drag being applied, so go ahead and aerobrake. If you're not using DREC there's not much to worry about. With DREC you'll have to be careful not to overheat or you'll need a heatshield, but otherwise it's the same deal. As a side note, if, by any chance, your vessel is *winged*, you can do some pretty cool stuff with aerobraking. Set a periapsis that is in the high-to-medium atmosphere and (for added awesomeness and, in fact, realism) flip the vessel upside down and come in inverted. When you get to periapsis, point a bit downwards, trim and use SAS such that your (negative) lift balances the centrifugal force and keeps your altitude constant so that you don't fly off into space again. Keep flying like this (it will take some time) and maybe going a tad lower as you slow down and you'll get captured no problem. Be warned, however, DREC can give you problems with this method as the craft tends to heat up quite substantially.

Is mechjeb telling you that? That's because FAR changes the way drag is calculated, which involves messing around with the stock values which mechjeb (and other mods) checks. So don't take these into account. With FAR you shouldn't need to worry much about terminal velocity though, the atmosphere is much more lenient than the stock "soup". Just keep your TWR within reasonable limits and you'll be fine.

True, I forgot that KSC is on the equator I've been playing too much Orbiter lately I think...

Nathan explained the reason, I'll suggest some solutions: 1) Launch when the Mun is about 3.5-4 days before one of the nodes (that's how long it takes to get there). That's when it's around 45 degrees behind the node. 2) Launch to a heading that minimizes the relative inclination (which you can get by targeting the Mun). 3) Use an off-plane transfer (don't match planes, find a single burn - some normal/antinormal component included - that gets you directly to the moon), or a 2-plane transfer (start your trajectory at your plane and change it mid-course to intercept the Mun) to get there. If your relative inclination is relatively low (i.e. you launched at a proper heading), the off-plane, direct method is the most efficient. Whatever you do, however, do NOT change inclination in LKO. Also note that the higher your inclination is when you *reach* the Mun, the higher your encounter velocity will be (and the more dV it will take to circularize an orbit), so try to keep it low if possible (although the difference is not too bad).

These two forces produce the exact same moment. You can either project the force perpendicular to the arm (which is what you did with the green arrow) or project the arm perpendicular to the force (which is the blue case). In both cases the projection factor is the sine of the angle between the arm and the force (as per the cross product). In particular, the dashed green arrow is sinθ times shorter than the green (or blue) arrow, and the 2nd moment arm is sinθ times longer than the 1st. These cancel each other out. Although, the demonstrated identity that (R + c*F) x F = R x F should have convinced you already. a.g. is absolutely correct on this one. The only thing that matters for torque is the magnitude of the force and the distance of the *line* of the force from the pivot. Not the actual application point along this line.

You'll be much better off with an actual orbital reentry. Suborbital flights reenter very steeply, and at 4km/s you're pretty much dead. An orbital reentry is much more shallow and allows you to stay high for longer, safely reducing your velocity. Remember, angle matters more than speed for reentry. Low angle = more total heating but lower rate, high angle = less total heating but higher rate. Here (according to your peak Gs) you are clearly exceeding the rate at which the heatshield can ablate. Therefore, you need to reenter at a shallower angle. Keep your apoapsis as low as you can to decrease the angle (i.e. increase your hop's range via horizontal speed, not altitude). If that's not possible, consider making a burn before reentry, retro and rad+ (up) to slow you down and "drag" the apoapsis over to your position. Also try to use lift during the reentry to keep you high for longer and keep the vertical speed low.

Huh, that's very weird. It's true, but weird I guess it might be the case so that all parts can make sound when they explode or something. I'll have to look into that further (but if it is for the explosions, then I suppose it's what we want, after all you shouldn't hear explosions in space). In any case it shouldn't be too much of a hassle (at least with my version) since all calculations happen once per frame (not per part). But I will definitely look into this a bit. Although we should focus on functionality first, you know how it goes with premature optimizations.