Murph

So, how do you know that it's used significantly less? Is there some stat site somewhere that tells you how frequently particular parts are used? If you factor in psychology, the fact that it has "Advanced" in the name might actually make it used more often, but that depends on the demographics as well.

That logic is flawed, as the IAS might be deliberately used for appearance, or as a way to add a little extra mass for balance of something. It should be left alone, just with the description clarified to let people know it's the same as the IRW. There is no real downside from keeping it as-is, no justification for removing it. I quite often use it when it's next to a decoupler, as it looks nice paired like that. The extra 0.2t is frequently irrelevant. Alternatively, and probably much better in the long term, make it a slightly stronger torque force. E.g. IRW: 20 torque IAS: 30 torque ASAS: 50 torque (and give this one a sane connection strength too…) As for needing a 0.625m part, I don't see the need myself. If a probe is all 0.625m parts, the probe core is probably sufficient. If you need more torque for launching the probe, just include a wheel in the launcher and benefit from a smaller, lighter probe, and probably a much stronger connection between the torque force and launcher stack.

Thanks for the suggestions, but they are not all that practical in this case. It basically requires the entire runway to reach takeoff speed, and the gear positions are pretty much as good as they can be, while keeping the part count reasonable, the gear structurally sound, and the chance of a tail strike down (it's got a Concorde-style tail wheel because the margin is already so slim, mounted high so not preventing rotation). It's not just wide, it's also long. If it stays perfectly aligned to the centre line on the takeoff run, it has about a 50/50 chance of the wingtips clearing the lights ok. Keeping it perfectly on the line, that's hard. It doesn't need more thrust or lift really, as it's got narrowly enough to takeoff fully loaded and ascend without fuss, if it wasn't for those damned lights. Yes, I'm kinda pushing the limits, without just throwing more power into it, but I'm an engineer, and I like trying to push for max out from min in.

The big lights at the ends of the runway (the 4 corners) are proving to be a serious annoyance to me. I've been working on a heavy transport fuel delivery space plane which is pretty much exactly the width of the runway concrete, and 200t fully loaded, so needs the entire runway length for takeoff. It flies just fine (for a large, heavy transport plane), hits orbit nicely with useful payload, looks reasonably realistic, etc. The major PITA is that it is extremely difficult to takeoff from KSC due to the wingtips and outer engine nacelles only just clearing those lights. Building the wings and nacelles higher is not an appropriate solution  the fault is with the runway lights, not the plane. I think the lights need to be reduced in size and/or lowered, as they seem stupidly large and high to me, for a runway edge feature. I suggest making them flush with the ground, embedded in the ground, or non-collidable, and with safe clearance for a wing on standard landing gear above them. If they are intended to be PAPI lights, they are wrong on 2 counts  no sectoring; and PAPI lights are pretty much always positioned safely to the side of the threshold, generally very low on the ground, commonly on the grass, not even remotely close to where a wing might legitimately be. PAPI lights are also usually a single group of 4, not 2 groups of 2, separated by the runway.

I'm about 90% certain that this is purely a cosmetic issue and isn't actually slowing anything down, just throwing spurious warnings out when one of many batteries hits zero. I've not timed it, but it looks to me very much like the transmissions continue without issue, despite the spurious warnings. It is a bug, but I suggest just ignoring it (unless you're Squad, in which case, please fix it…). It may well be a general bug with the resources system, as you sometimes see and hear a flameout when one of many fuel tanks hits zero, if you happen to be paying attention at the time. It's so brief that it doesn't cause any asymmetric thrust issues, and likely isn't noticed by most people.

The Steam client should have a "browse local files" option in the properties window for KSP. Right-click on KSP in your library, and select properties from the menu. That should open a window on the main KSP install directory (buried a few levels deep inside Steam's data directory by default). You'll know if you're in the right place by the presence of the GameData directory. That's just to help you find the location. Once you know where it is, you can go direct to it, no need to go via the Steam client app. While you're there, take the opportunity to backup your saves, craft files, etc.

Congratulations, that's spectacularly inefficient, if you're talking about killing any significant amount of velocity when directly overhead. That potentially means a significantly bigger craft to start with, if you end up needing to carry another tank to fuel the burn. If you time the de-orbit burn correctly, there should be no need for anything other than relatively minor corrective burns inside the atmosphere (NASA corrected with just aerodynamics from a simple, but clever use of offset CoM, in the case of Gemini and Apollo), and possible final vertical deceleration burn for landing (if you are doing that). The very fact that the question has been asked about the maths tells me that the OP is interested in doing the efficient, "correct" method, not the brute force one. Here's a starting point which might work. It's what I use for generic spaceplanes inbound to the KSC runway. It will likely need tuning for use with capsules, or if you need to start from a different orbit. Starting with a near perfect, 100x100km circular, equatorial / 090º orbit, I do a retro burn 180º from KSC, i.e. when I'm directly on the far side of the planet. I reduce my periapsis to 35km directly over KSC. This drops me down nicely to about 10km approaching the mountains west of KSC, for a little powered flight in. I usually hold about 10–20º nose up through re-entry, until I re-establish conventional flight. So, adjusting for capsules with parachute final descent. Try maybe 40km or 45km periapsis directly over KSC, or do the retro burn just a little after you pass 180º from KSC. Some experimentation will be required. I have a flag permanently planted at KSC so that it's easy for me to see it on the map view, even when it's night there. Alternatively, get MechJeb to do it and learn from what it does. Edit: That's on stock aerodynamics, not FAR, but hopefully still gives some food for thought.

With a 77Mm apoapsis and a 93km periapsis, you'll be getting near enough zero aerobraking, as you're not deep enough into the atmosphere to get much effect, and will be travelling so fast (due to the extreme apo) that you'll be in and out of the atmosphere in a flash. So, it's more likely just rounding errors or something like that. Movement of the ship (changing attitude) can cause the numbers to jitter a little as well, it could just be that (it's a very small % change). You need a periapsis of about 80km or less to get much aerobraking, if memory serves. At a rough guess, you'll need a periapsis of maybe 70-75km on your next pass to pull your apoapsis down about half way towards Gilly, but it's been a week or 2 since I last skimmed through Eve's upper atmosphere. Don't go below 70km unless you're certain of the required altitude, as it quite soon becomes a landing below that. Edit: You can see the near zero aerobraking in your engineer numbers there, less than 1kN of drag at periapsis, likely not enough to make a measurable difference to your >4km/s velocity, and certainly orders of magnitude away from the force you'll require to pull that apoapsis down towards Gilly quickly.

The maths are certainly out there, NASA have been doing it since at least Apollo, using the aerodynamics of the capsule itself to adjust the descent during re-entry, and with only the minimalist on-board computing power (remember the low data rates, tiny memory, and comms blackout periods during key phases of re-entry  the re-entry data was transmitted from mission control before re-entry started). I think Gemini was a precision splashdown as well, and the Shuttle was fairly high precision as its gliding abilities were only marginally better than an aerodynamic brick. Precision being measured in nautical miles, of course, not feet, for the Gemini and Apollo capsule splashdowns. Of course, much of the precision does come from having the correct initial velocity vector before re-entry starts, which certainly can be assisted by terrestrial computing. Mechjeb 2.1 certainly does a not bad job of de-orbit burns to drop a capsule on the grass at KSC, at least some of the time (it has an odd fail case if you ask it to land from a highly eccentric orbit). That's with stock aerodynamics, etc.

The shock force when the chute opens is just too much for the link between the capsule and the rest of the ship. There's 2 major factors which cause this in 0.22: 1) Chute shock force is much too harsh. 2) Parts are held together with duct tape and used chewing gum, unless you go nuts with struts. There are some things you can try, however. You need to reduce your speed as much as possible before the chute opens fully. You can do this either by trying for a much longer aerobrake (shallower angle into the atmosphere), some judicious retro burning during descent, or opening the chutes as early as possible (trigger them as soon as you begin your descent, then let them open automatically as atmospheric pressure rises). The partly deployed state provides some useful drag, before they go to fully deployed and give you the problematic shock load. You can also try using the orange/red drogue chute on future builds, in addition to normal chutes. You certainly should be able to strut the connection between the decoupler and tank, but only in the VAB, not on the mission (without mods). 27t is reasonably heavy for a parachute lander, so plenty of struts, plenty of chutes, and some judicious retro burning are most likely the answers. If the radial chutes are attached lower down the stack, you could try triggering them before the capsule chute. If you don't care about your exact landing spot, circularise your orbit just above the atmosphere, e.g. at 42x42, then drop just barely into the atmosphere, e.g. 40x42 (it starts at 41, if memory serves). Then just let it orbit, with all chutes triggered, and let the orbit drop slowly. Experts may have a better strategy, but I believe that should give you approx max aerobraking. Just before the chutes fully deploy, use retro thrust to reduce velocity to a manageable level (trial and error will be required to figure out just what that is). You might also want to describe your flight profile more fully, as the starting orbit for your descent will make a huge difference. E.g. if you start at a 500x500 orbit and go straight for the lower atmosphere, you going to be carrying LOTS of velocity into the aerobrake then chutes. Start the descent from as low an orbit as possible to minimise the speed.

If you have multiple command modules on the ship, and/or docking ports, try right clicking on different ones and selecting "Control From Here". The navball shows relative to the currently selected control point (and sideways or upside down, if the control point isn't facing up/forwards). I'm not sure how it picks the default, probably the first one it finds traversing the part tree from the root (frequently the root itself will be a command module). Command modules means both manned and unmanned modules, so probe cores, etc, as well as pods and cockpits. Edit: Oh, and being pedantic, blue on the navball is not prograde. Prograde and retrograde don't exist until you are moving, and can be anywhere on the navball, determined by your current/instantaneous velocity vector. It's pedantic, but an important distinction, which could cause confusion. Also: http://xkcd.com/1133/ If the fire is pointing towards space, you are having a bad problem, and you will not go to space today.

To be honest, I don't see either of those flaws in the Aeris 4A. If you keep the nose within about 30-45º of the prograde vector, with SAS enabled, it handles ok, so the instability doesn't make it unfit for purpose (successfully doing a round trip from KSC to 100km circular, and back). The instability only really bites if you let it get out of the envelope in the first place, although I do prefer it with bigger canards on the nose, and a few other tweaks. Intakes? It's got more than enough to get past 20,000m, then more than enough rocket fuel to hit 100km orbit from there, de-orbit, and have a bit of fuel left for some atmospheric powered flight back to KSC.

Try the Aeris 4A tutorial mission on the wiki: http://wiki.kerbalspaceprogram.com/wiki/Tutorial:Aeris_4A_mission Just load the stock Aeris 4A, and replace the supplied LV-T30 with the Toroidal Aerospike for the sake of sanity (it's difficult to avoid leaving the LV-T30 on the runway when you rotate during your takeoff). Launch, and follow the detailed step by step instructions. Once you can happily get the Aeris 4A into a 100x100 orbit, you should be in a much better position to figure out what you're doing wrong in terms of design, and/or piloting for your own plane. It's pretty much the best of the stock aircraft, the only major flaw is the LV-T30 hanging off the back of it. With a few tweaks, it can be a really good 100km spaceplane (it's basically ok as-is, the tweaks take it from ok to good), and gives you a baseline to compare against.

One thing to consider, is that doing full Apollo style Mun missions is great for practicing orbital rendezvous and docking. Both are actually quite easy once you get used to doing them, despite seeming really very hard initially. Mun missions are fantastic for learning those skills, which may prove very useful for missions to more distant places, where it's simply not practical to carry the return fuel down and back up on the lander.

A very minor bug to report with the B9 UL-1 Kornbluth. It has the 2m LFO tank, instead of the 2m fuel tank, meaning that it's carting around unusable oxidiser, and half the fuel it could be carrying for the same weight and balance. Maybe it's intentional for some reason that I'm missing, it just seems like it was a minor construction error. It can be fixed in about 10s with a quick ":%s/Body.LFO/Body.Fuel/g" on the craft file in vi, saves having to redo the struts, wing sections, etc. Seems like a nice little terrestrial plane apart from that. Thanks for providing a much needed, very nicely thought out and created, and very useful set of parts!

You may well have tested sufficiently to know for sure, so I'm not saying that you're wrong… They are extremely efficient, but they are also HEAVY. Are you certain that 4.5t of a pair of LV-Ns is actually better than a 2.5t Poodle, 1t of a pair of LV-909s, or maybe even 0.5t for a single LV-909? To me, there's a minimum dV requirement before a LV-N is actually a real benefit. If you're using them for landing, ascending, then return to Kerbin, the transfer burn back to Kerbin probably makes them worthwhile. If they are only for landing and re-ascent, with a different engine powering the long orbital transfer burns, I'm not sure they are the best. A useful setup might be to use the same LV-Ns for orbital transfer away from low Kerbin orbit, landing, ascending, then transfer back home. Something like that might really allow the LV-N's efficiency to make a big difference, despite their very poor individual TWR. Personally, I like the LV-Ns for long transfer burns, but prefer the LV-909 or Poodle for landers, and for Apollo-style returns home with just the CSM. As far as landing with the return stage or not, I'm not sure. I do like doing it Apollo-style, it's interesting and fun. Mun is probably about the heaviest gravity where it does make some sense to land with the return stage and fuel. My gut feeling is that it's really 50/50 which is better for Mun. Any heavier gravity, and the fuel for returning to Kerbin is probably better to stay in orbit, I think.

No, it doesn't. A simple test you can try to prove it is to queue up a bunch of data so that you're going to be transmitting constantly, from a craft where the solar panels don't produce enough power to sustain continuous transmission. At 1x time, the battery will steadily drop to 0. At a faster time rate (might be 5x, 10x, 50x, depends on your craft, sun angle, etc), the battery will basically hold steady. At an even faster time rate, the battery will recharge. Easier is, of course, to use a stop watch to just time transmission of a large volume of data, the transmission rate remains unchanged for all time warp settings, takes the same real world time regardless.

Yeah, it is quite clear for someone who has a reasonable basic understanding of data networks, transmission, etc. The water pipe analogy is just often a good way to explain bandwidth/throughput to the layperson.

Think of the data as water in a tank. Throughput is the size of the pipe draining that tank (when it's active).

Yes, they are not too different in concept, with the core of a turbofan essentially being a turbojet, but for significantly different design reasons. The pure-turbojet bypass air doesn't go through fan blades, it's ducted direct from post-intake into the afterburner chamber. With a turbofan, the bypass air is taken after the first stage fan blades. The turbojet's bypass is all about cooling, controlling the speed and pressure of combustion air for the turbojet itself, and providing combustion air for the afterburner. The high-bypass turbofan's bypass air provides additional cold-air thrust (i.e. the bypass air is accelerated mechanically by the fan). The bypass air also provides a noise reduction benefit, with the cylinder of cold air absorbing some of the sound from the jet combustion, something which often is of little to no concern with an afterburning turbojet. Then there's the low-bypass turbofans with afterburners, just to blur the line down the middle.

The SR-71 used a turbojet, not turbofan, unless I'm mistaken. It was a fancy ram intake, high bypass turbojet, and afterburner, with much of the thrust at Mach 3 being from the afterburner. In some ways, a hybrid turbojet / almost-ramjet. That was 1960s technology, and it's suggested that modern technology could easily take the SR-71's general design from Mach 3+ to Mach 6+. One of the major limiting factors for it was engine temperatures, which is something where modern materials and design can make a big difference.

Very often I think this can be caused by a plane lacking sufficient structural rigidity, so flexing causing what should be a good wheel geometry to become bad. A couple of carefully placed struts can often help fix that aspect of it. You can watch for it flexing when it's initially dropped onto the runway, and if you apply pitch/yaw/roll controls while it's stationary. If you see much flex in either case, that could be the root cause of the problem. The stock Aeris 4A, for example, shows notable flex around the RCS tank, docking port, and IAS. I disagree quite strongly with adding reaction wheels to solve stability on the runway during takeoff runs. To me, that suggests that there's a far more fundamental issue with the structure and/or balance of the plane, if you need extra torque just to hold it steady during the takeoff run. To me, the reaction wheel torque should only really be important once you're above the altitude range where aerodynamic control surfaces can operate effectively, sized appropriate for control from 30km up to orbit, and in orbit. That's assuming we're talking about a modestly sized craft which looks vaguely like a plane, of course. Giant or bizarre craft may well require a more unconventional approach. Another issue which is difficult to be certain about, but I became highly suspicious of, is the highly erratic prograde vector which can sometimes be seen on the nav ball when the plane rolls slightly after physics starts, but before you have actually applied power, etc. I can't be certain, but I think that if you turn on SAS at the wrong moment, while the vector is jumping around, SAS can lock onto some wildly inappropriate vector, and actually drag the plane off trying to follow it. The solution I use is to hold the brakes on, then turn on SAS, apply power, then release brakes. It's difficult to say with certainty, but I'm pretty sure that holding the brakes on like that has eliminated most random runway excursions on takeoff for me (for craft which are otherwise generally ok for takeoff runs).

No, not really, they should just honestly acknowledge when a ship uses a cheat and/or hack. That's my way of looking at it, that there's nothing fundamentally wrong with cheating/hacking in KSP, if you openly acknowledge that you're doing so. As for other areas where the game is currently less than fully realistic when it comes to physics, etc, I feel there's a major difference between that and stacking intakes. The game doesn't really allow stacking them as an obviously intended mechanic, it requires a specific exploit of putting something very unrealistic onto the existing intake's front, and/or hiding them with clipping. In time, there's a good chance that the KSP physics model will gain more realism, and it's understandable that the devs have omitted certain things from it at this stage, preferring a simpler working system for now, then adding more realism to it as and when they can. There is one circumstance where I'd feel that it's much less cheaty, and that's if you are using it to actually model something real. E.g. the supplied turbojet isn't actually that far away from the RR Olympus performance in terms of thrust, but requires 2 ram intakes to achieve that to roughly the same service altitude, where RR managed it in a single tube (RR Olympus 593 in Concorde was 169kN with a service ceiling of 60,000' / 18,300m). If there's some case-specific rationale for limited stacking along those lines, to simulate a real world component without the effort of creating a completely new part, I can get behind that thinking, considering it more of a justified hack rather than cheat. I could quite easily get behind the idea that KSP actually needs a ram intake which has significantly higher performance than the current one. Spamming them with impunity, however, I'll always see that as cheating. As I said earlier, however, go right ahead, KSP rules are whatever you want them to be, more or less. For me, most of the time, I get much more satisfaction from KSP by trying to stay as close to realistic physics as I can.

Almost cheaty?!? To me, you might as well just debug yourself infinite fuel, hack the numbers in part.cfg for the intakes and engines, or edit your stuff into orbit, if you're going to just stack or hide absurd numbers of intakes in completely unrealistic ways. Each to their own, though, and KSP is very much a sandbox where you get to make up the rules as you go along, so go right ahead and cheat intakes all you like, just please don't pretend that it's anything other than a hack or cheat in terms of realism, particularly physics. Have fun too, by all means, such as figuring out what combination of SRBs best achieves a one way ticket to orbit for an intrepid Kerbal sat in the chair-o-doom on top of them, it doesn't all have to be realistic. ;-) As for the original topic of upgrading the Aeris 4A, it's really just a case of increasing the area (i.e. length and width) of the wings, adding more fuel+engine tubes as you go, keeping an eye on the CoM and CoL, until it can do what you need it to do. There's plenty of trial and error, which is half the fun of KSP for me, figuring out all the ways to create smoking holes beside the runway, prior to achieving a "perfect" design which just works. Aside from some relatively minor irritations with it, it's not such a bad basic design, can be made to be a very easy runway to circular 100km orbit design with only some very minor tweaks (it can do 100km with ease as supplied, just needs some tweaks to make it completely easy). Thinking of the supplied craft as a trainer is probably best, as it's pretty good for that, both in terms of training you to fly up to orbit and back, and how to fix or tweak a basically ok design from mildly irritating to good, and beyond.