arq

I suspect that this was there to allow people to edit the CommandPods to add KER. So this statement would be true if 1) KER is attached to a part or 2) someone modified a CommandPod's .cfg to include Engineer. However, I'm making stuff up now because I have not looked into the source code (or the source of any mod, for that matter) any more than the one line you excerpted. You could be entirely correct that that condition should be removed.

As others are suggesting, this is true if you are already at Mun's orbit. From LKO, it's better to burn straight for Eve than to raise your orbit to Mun and then go straight for Eve. In terms of dV cost, {Mun -> Eve} < {Kerbin -> Eve} < {Kerbin -> Mun -> Eve}. An LKO/Keostationary transfer is significantly lower in altitude than Mun but costs roughly as much as an LKO/Eve transfer.

This. Also, as much as I enjoy the design part of this game, I find the piloting aspects to be even more fun. I'm glad you found a change that allows you to better enjoy KSP.

Shooting ideas out my butt, but just based on the label I would expect it to be some sort of automatic gain control (AGC) that makes the sound louder when quiet and quieter when loud, so that you can hear stuff (and not have your ears blown out) regardless of if you're drifting through the endless void or sitting atop a 3000t rocket. If my guess is correct, then 'responsiveness' controls how quickly the filter reacts to new data. A fast responsiveness will adapt quicker but may overreact to something loud and short like an explosion, whereas if it is slow it will be steadier (and more accurate) over time, but may take some time to converge to that state. 'Threshold' is more mysterious to me, but I would guess it is some regularization that keeps the louds slightly louder than the quiets (and vice-versa) so that the AGC does not wash out all of the dynamic range. These values are unitless because audio is generally dealt with in unitless quantities (since you have a speaker amplifying everything, adding any units would be a waste anyway). However, it is likely that 'Responsiveness' corresponds to the forgetting factor (or maybe its logarithm) for a single-pole IIR filter that acts on the audio energy over short time windows or individual samples. Based on my assumptions, a model for the Normalizer could be given by this recursion: a[n] = (1-R)*a[n-1] + R/sqrt(T + x[n]^2) y[n] = a[n]*x[n]; where a[n] is the gain at time n, T>0 is related to 'threshold', and 0<R<1 is related to 'responsiveness', x[n] are the raw audio samples from the game and y[n] are the normalized samples

I, too, would love if there was an aerobrake/landing calculator separate from MechJeb.

Landing on the docking ports of vessels is very tough. Practice on Kerbin first, definitely. Also, Duna's atmosphere is thin enough that LVNs still have very high ISP even at sea level (at least 500, though IIRC it's over 700), so they are often a very good option for anything but the lightest landers. If the TWR is an issue with them, LV909's are rarely a bad choice. As far as chutes go, it is *possible* to get to 5m/s on chutes for landing, but actually I would argue much less efficient. Parachutes are very very heavy. You lose a ton of dV just hauling them around. It's actually possible that, round-trip, it's cheaper to not use parachutes at all. Terminal velocity is ~150m/s near Duna's surface. I expect that for most ships the cost of getting 500kg (or much, much more) worth of parachutes from Kerbin to the Dunan surface is more expensive than that. To get a ship near Duna's surface to land with chutes at 10m/s means that you need approximately 9% of the lander's mass to be parachutes. I find it hard to believe that getting an extra 10% of your lander's mass into orbit plus the 1000m/s from LKO to Duna (and possibly the 2000m/s back to Kerbin) is cheaper than using some rockets to assist the landing. Approximate calculations below: DragNeeded = (TerminalV/DesiredV)^2 * 0.2 ChuteMass/TotalVesselMass = DragNeeded/500

Strap on moar struts and moar boosters and send him on his way.

As a note, if Kerbin did *not* have an atmosphere, it would be most efficient to, from Mun, burn retro to Mun's orbit until your Kerbin periapsis is at the desired altitude, wait until you reach peri, then burn retro again to reduce your apoapsis. This is called a Hohmann transfer, and is most efficient for most manuevers (excepting a few where a bielliptic transfer is slightly more efficient). But as others have suggested, aerobraking is, when possible, by-far the most efficient technique for lowering an orbit or for capture in a body's SOI.

Yup, radially mounted or clustered engines often get twisted ever so slightly to one side under load, which causes the rocket to spin. Moar struts is typically the solution.

I avoid stacking air intakes in front of each other, but sometimes I'll put them on the front of a bi/tricoupler. Still, I do this sparingly. Also, they always go on the front of a fuel tank and I avoid having fuel tanks without engines. At the end of all this almost all of my SSTO's end with an intake/engine ratio of 2-3. Once you start getting up in the 4 or 5 range (or higher), I start placing it in the 'airhogging' category, because it is significantly in excess of what is necessary to get to orbit. I tend to avoid that. Ofc, my SSTO's have only ever made round-trips to Minmus. If I wanted to go to Duna in one, for example, I would have difficulty unless I added some more intakes. But ultimately it's a sandbox. I consider airhogging 'SSTO easymode' and avoid it for the design challenge, but the game is in the eye of the player. Also, if your goal is to create and SSTO lifter and not the act of merely creating an independent SSTO (maybe you enjoy launching payloads on the backs of planes more than the tops of rockets?), then airhogging is probably necessary to get anything but the smallest payloads into orbit.

Great work so far! What I would really love is a way to make randomly generated planets and star systems. It would really help with the fun of 'discovery and exploration', as when you get bored of the Kerbin system you could just generate a new one and have at it. This would also work well with telescopes and some form of 'discovery' for celestial bodies. Of course this comes much later, like after we actually have hand-designed ones. 'libnoise' was used to generate Kerbin (and probably many of the other bodies), why not set it to work generating planets for more systems?

Technically, yes. But if the gimbal is limited to 1deg then the loss is limited to 1 - cos(1 * pi/180) == 0.00015 == 0.015% Of course, this is assuming a lack of significant wobble in the rocket. Still, if the rocket wobbles 3deg (a lot!) and your gimbal is still going crazy then your inefficiency is still limited to 0.0024, or 0.24%. These should be upper bounds, so your actual loss should be less. And both of these issues will be fixed (at least mostly) with 0.21 and the new ASAS.

Do you consider it cheating? That's all that matters, it's a sandbox. I tend to avoid it, but that's personal preference. If nothing else, it makes clicking parts difficult.

I chose instead to answer the question: "When KSP is released/finished, if Squad were to announce KSP2, would you buy it?" Yes, I would. I've got my $23 worth out of KSP long ago. I think that Squad would have benefited greatly from the lessons of KSP and would produce a much more polished game were they to start over. I would expect it to have a better physics engine, as my first wish.

They could add some sort of 'saturation' tracker to recognize when the wheels could no longer provide control, and they could passively de-saturate over time (imagine magnetic torquers doing that bit). It would be equivalent to an overheat system, though without exploding upon saturation (technically, turning the opposite direction would also de-saturate the wheels, but that would be too troublesome to track). ...But honestly, I don't see such a mechanic adding to the game in a meaningful way. Just pretend they have limits and use them sparingly, if you really want.

I like this suggestion. Usually I resort to using small hardpoints in the radial scenario. A 'not in staging'/'locked' stage would be very useful.

I assume you're referring to the readouts of Kerbal Engineer? It is a known bug that Engineer doesn't handle SRBs correctly (it generally likes to ignore them). I don't know how much the SRBs added to your dV, but yes they certainly added some.

Yes, FAR can dramatically reduce the delta-v to orbit (assuming you actually heed the aerodynamics changes). I've plugged it in a few times, but it makes planes considerably more complicated to design so I usually get frustrated and uninstall it. Maybe after 0.21 and the ASAS changes I'll give it another go. For an optimal ascent with stock aerodynamics, you want to stay as close to terminal velocity as possible (this isn't really practical above 15km or so, as the atmo drops off very quickly). You can look up tables on the wiki, or get readouts from Kerbal Engineer (and probably Mechjeb?). In stock, about the cheapest I've ever gotten to LKO was around 4200dV (measured using Protractor's counter), but that was with a light, powerful rocket that was able to accelerate quickly during the gravity turn. Heavier rockets with slightly lower TWR tend to require closer to 4500dV.

If you launch straight from KSC out to a 2868km apo, then raise your peri so that you have a 4-hour orbital period (use Engineer, Mechjeb, or double the time difference between your apo/peri), and wait 1 or 2 orbits like that, you will get an apo very close over KSC. Scott Manley has a recent YouTube video about geosync that does that. Otherwise, from geosync, if you drop your orbit slightly you will move faster relative to the surface and you you raise it you will move slower. The issue is that you want to be at 2868km when KSC goes under you. Remember, the most important part for staying over a place on the ground is to have exactly a 6-hour orbital period. Really, without a ton of extra work, most of my geosync orbits vary by maybe 5km, but I use engineer to get 0.1s/orbit synchronization so they don't drift.

KSP is not a graphics-intensive game. Any mid-range GPU should do fine. The real killer in KSP is all the physics calculations in the CPU, that's what you would want to indulge on. Specifically, the speed of an individual core, since physics all falls to a single core. In the future, if they can split physics between cores, then having a few may help (though more than 4 will probably suffer from diminishing returns). If they can offload some of the physics to the GPU, *then* it might matter more.

Some quick numbers: For about 950dV you can get out to Minmus's orbit (with or without an intercept). On an elliptical 100km-50Mm orbit, your speed at apo is tiny, maybe 50m/s. That means that for 100dV out there, you can completely reverse your orbit (or go to any other orbit for slightly less). Then, with some aerobraking you can get back down almost for free. This means that for around 1100m/s you should be able to change from any LKO to any other. Of course, there's no cheaper way than to simply launch in the orbit you want.

You can plan the burn with the purple markers on the maneuver node. If you want to do a massive change of inclination, sometimes it is most efficient to raise the altitude of your ascending or descending node (make it the apoapsis) and do it out there. Inclination adjustments are more efficient at high orbits because you have lower speed at that point (so inclination burns are larger relative to your speed). As said above, you can only burn to change your inclination to be as small as your current latitude, so it's important to do this at the equator. For large changes you can use moons to make inclination changes. If you get an intercept and pass close to a moon its gravity will change your orbit, including inclination. Use maneuver nodes to plan this. However, Mun is roughly 800dV away from LKO, so it will likely cost you around 1600dV to use it for a change and return to LKO. This is a lot, but changing from an equatorial to a polar orbit directly probably costs roughly 3000dV, so it can still be cheaper.

Though in my experience, S is a much safer way to slow light objects in low-g. Brakes sometimes have a tendency to flip things. Tapping them repeatedly generally gets around the issue.

I commonly experience the same issue (actually, I was wrestling with it last night for a 1-launch land-on-everything-but-eve trip, haven't finished working it out yet). Usually I can make it launch after several hours of tweaking, but I agree it's a pain. Also, all the struts jack up the partcount. I'm contemplating adding the welded-parts mod to drop the partcount, but I'm not sure that it will fix the problem. A few notes from my experience... Sometimes removing a strut is better than adding one, especially when your ship gets above the 1500t mark. If a part is strutted-out-the-wazoo and still breaking, it's possible that your struts are directing too much force through that part. In this situation, if you can 'route' some of the force through other parts it may help. I find tanks at the top of stacks (especially on asparagus stages) to be especially prone to this, and often I leave them nearly or completely without struts. As a means to redirect force, one effective technique I've found here is to replace upper rockomax tanks on boosters with t800 tanks, stacked much higher to keep the same fuel load (1 x32 == 4 t800's). Of course, this only works on outer boosters where there is nothing above them. These taller stacks make fantastic supports to strut to your payload, moving more force to the top of your rocket in addition to stabilizing it against wobble.

Yup, the more time you spend on a suborbital trajectory the more dV it will cost. As stated above, the most efficient approach is to start from as low an orbit as possible, burn full retrograde to drop most of your horizontal speed, and then land from there. The lower and faster your vertical ascent (after ditching horiz), the more efficient.