Banbite

Fractions are also more accurate, they don't have the same amount of floating point rounding errors as decimals do, I think. But both has their uses, decimals are easier to read but fractions are easier generally better to do math with. And also stuff like 1/3 vs 0.3333333... etc.

Lazors are always the solution Or save file editing

Well for rockets it's more likely that the mass varies during the time, leading to some interstingly complex equations.

Well, since stuff tends to disintegrate on collision instead of shattering into a lot of tiny little pieces I don't think it would be possible.

Ye, that kind of ruined that theory but still, it isn't less unrealistic than the extreme mass material

My guess is that the Kerbal universe is set in a different universe than ours in which the gravitational constant is much higher than it is here. So their planets isn't actually that much denser than ours, it's just that they need less mass to get the same gravitational pull than us because of their higher value of G. But then one can wonder what other effects that a higher G can have. Like stars needing less mass, gas giants starting fusions and some other mumbo jumbo. But that's just how I see it. It's about equally science fiction that the extreme densities.

One idea that floated around this thread was that the ASAS should only use RCS if it was needed, so big corrections. So it should only uses the reaction wheels for small corrections and the only use the RCS if the reaction wheels (maybe also taking engine gimballing and aerodynamic control surfaces into account) can not provide any more torque. This requires some programming vodoo too make work, a big point being to know beforehand how much torque the RCS can provide, but it should definitely be a big step towards solving the ASAS wobble.

Destructive lithobraking, would be a fun thing to try.

Well the stock ASAS unit needs some tweaking, in a couple of areas. Making it adaptive is one thing, so it adapts the PID-parameters after the size of the craft (and maybe available torque) is not that hard to do (if you neglect the I-part which in 99% of the cases is completely unnecessary and just always adds overshoot, windup and nasty stuff). And then it's the stuff around that, one thing is that instead of feedbacking to % of control output it should instead feedback to the amount of torque it produces. So for example activating RCS will instead of making it go haywire just reduce the control outputs so it produces the same amount of torque as before. But that requires some nifty programming to calculate the amount of torque the RCS-thrusters can provide in each direction so it has something to go after as well as the torque provided by gimballing engines (and control surfaces maybe if it's not to overkill). And then there are the biggest stuff which would be really appreciated, flex compensation and RCS balancing. But I trust you Harv that you will come up with something to fix that And regarding to that attitude setpoint, it would be nice if we could snap that to the prograde/retrograde/normal/../Nodes etc (mechjeb style), and maybe even have an extra Navball icon to show where it is currently.

Reinforce the engine with struts between the fuel tank and the engine, that tends to fix it for me.

Left click and drag the mouse left and/or right

This is a great use for keplers third law: (orbital period)^2 is proportional to (semi major axis)^3, or T^2=k*a^3 where k is an arbitrary constant which is the same for all orbits around a body. I just did something similar but with 3 instead of 4 satellites so I know this works. So math: Seeing your problem the second orbit should actually have a orbital period that is 3/4 of the equitorial orbit, so T2 = 3/4*T1 where T1 is the orbital period of the equitorial orbit and T2 is the period of the "deploy" orbit. This will make the satellite end up 90 degrees in front of the other satellite This gives that T1^2/a1^3 = T2^2/a2^3 => (T2/T1)^2 = (a2/a1)^3 which gives: a2=(T2/T1)^(2/3)*a1 This gives us the ratio between the "final orbit" and the "deploy orbit", and if T2/T1=3/4 then a2=(3/4)^(2/3)*a1 = 771/934*a1 = 0.8255*a1 To see what this gives for Pe for the deploy orbit use the following formula: a = (Pe + Ap + 2*R)/2, where R is the radius of the body, for the Mun R = 200km. Assuming the "final orbit" is circular the Pe of the "deploy orbit" gets: a1 = Ap+R; a2 = (Pe + Ap + 2*R)/2; a2=0.8255*a1; Pe = 2*0.8255*(Ap + R) -Ap - 2*R Example: If your final orbit has an altitude of 500km then your Pe becomes: Pe = 2*0.8255*(500 + 200) - 500 - 2*200 = 255.7 km Just punch in your own Ap to get your value of Pe. When you're deploying the satellites you can make one orbit with the first, two orbits with the second, and three orbits with the third and you should have everyone in a nice 90 degree separation. Or you can redo the calculations with T2/T1 = 1/2 and 1/4 and do everything in one orbit, but you're likely to crash on the 1/4 one if you're Ap is to low.

Middle mouse button does something like that. But if you want to take screenshots one tip is to zoom all the way out so you no longer can see the probe, if you don't want it to be in the way.

Balancing, in the real world it takes almost 10km/s delta-v to get to orbit, in KSP that number is 4.5 km/s due to the scaling. All other maneuvers like TLI and interplanetary burns also takes a lot more IRL. So not to make the game to easy so that the players actually have to design rockets which more closely reassembles the real world counterpart the easiest thing to do is upping the structure/fuel weight ratio as well as a bit heavier engines.

Had a go at this for an hour or two. Pretty difficult, but did a pretty good job of crashing into the pod and the ground. Will have another go tomorrow. Fun challenge and a fun to fly VTOL. edit: also had some problems with the lazor mod makes all the launch clamps explode when I decouple, have to fix that somehow.