pincushionman

Weight and complexity. It may seem like an engine that's not running is simply empty weight, but the fuel systems in particular become more than twice as complex, and structure now has to be good for wildly different load paths deending on which engines are on or off. You also can't usually close off intakes like we can in KSP, and if you could, it would also impose a significant weight and complexity penalty. Now, that's not to say multiple engine types haven't been used before. In the early days of jet power, turbojets had little static (ground/low-speed) power and responsiveness, and were unable to get naval aircraft off the shorter carrier decks of the time reliably (and, frankly were simply unreliable), so a concept called "composite propulsion" was investigated, in which aircraft had both turbojets and piston-powered propellers. This worked, but it was heavy and complex, and the real answer was of course better jets (more specifically the low-bypass turbofan) and the steam catapult. But for the application you describe, you'd probably be better off pursuing a combined-cycle concept like the J58 or SABRE @Streetwind described. At least that way you're getting two engines for the price of three, which is a lot easier to swallow than the price of six you'd eat for having separate systems. And you can just forget about hypersonic planes right now. We can't even get the hypersonic part to work well by itself yet, let alone in a combined application.

You know what's easier than editing the persistent.sfs to do this? Switch to the sats from the tracking center, then press Alt+F12 and use the debug orbit editor to set the parameters live. I just got done using that tool for some research, and it's fantastic. Just set the parameters to be exactly the same except for the mean anomaly and you'll be pretty close, keeping in mind the satellites will be moving while you switch and edit, so you may need to account for that between your four sats. Also, don't make them exactly perfect - add a tiny eccentricity and inclination or else the LAN and argument of periapsis (called LPE in the editor for "longitude of periapsis") will be non-unique and the orbit markers will start jumping around due to physics simulation. And keep in mind that inclination, LAN and LPE are measured in degrees, but your anomalies are measured in radians. it's kind nd of annoying.

I'm sure it can, but it depends on what it's doing when it crashes. If it's trying to write to the savefile, it'll almost certainly be corrupt. And autosave can hapen at some inopportune times.

May your flights go smoother than the guy on the right's.

I would suggest that adding such a warning the first time "high" tmewarp is engaged is enirely reasonable - just like the warning the first time physics-warp is used. The reality is, while we are certainly aware of the day-night light-dark cycle in real life, we don't encounter high rates of time passage…like, ever, except in KSP. The closest thing in popular culture would be time-lapse video, which is never that fast, and if it might be, you don't deliberately choose alternate light-and-dark exposures because that would distract from the subject. So even for an average, reasonable person, the result might be unexpected. Even in KSP you have to go out of your way to cause these effects. First, most timewarp - especially high warp - happens in map view. Second, high warp is disallowed except far from bodies, where revolution rates are low (or nonexistent for escapes) and shadow times are short relative to the orbital period. So little risk of flicker. You pretty much need to engage high timewarp while landed to cause this - and landed on a body that rotates fast enough for this to be an issue. And how often do you really do that? Drilling and refining? That's relatively late in the tech tree, and some people never do it anyway. You could play KSP for years and never need to high-warp in a situation that deliberate warp would cause a flicker issue. But you sure could do it by accident. And effects of accidental things are always unexpected. I say they just code in a warning.

Remember that what you actually want is horizontal speed - the only reason to go vertical at all is to get obstacles (terrain, atmosphere) out of your way so you can kick back and relax with that sweeeet horizontal speed. Any effort put into vertical acceleration is eventually lost, while the horizontal speed you keep forever. With high TWR, you have to dedicate more effort to vertical acceleration early, otherwise you'll be in too thick an atmosphere when you're trying to go horizontal. That means you have to bring more dV to the party high up to make up the horizontal speed you couldn't get earlier - so you end up paying for that speed twice. With a more manageable TWR, you can manage your turn much more effectively, adding significant horizontal speed while you're still deep in the atmosphere, but not yet going fast enough to risk losing control of your rocket. It's quite a bit more efficient to add both horizontal and vertical speed at the same time if you can. If you're good, you can be going nearly horizontal by 30-50 km and still be going fast enough to raise your apoapsis, not having to worry about vertical acceleration for the rest of the ride. If you're really good, you can thrust continuously from takeoff and make your orbit circular as you reach your target apoapsis. And no thrust is wasted. These stunts, however, are not possible if you have too high a TWR - you'll be forced to go vertical, coast to your apoapsis (which will rise really quickly), and make up for lost time when you get there. That said, though, it's easier to overpower your TWR somewhat and leave yourself some wiggle room. But don't overdo it, so you can get some significant horizontal speed on the way up, or you're going to be all kinds of screwed.

I suppose you could argue time of epoch is its own parameter, but beyond that I got nuthin'.

Stick a Clamp-O-Tron Jr. on the front, and "control from here" on it.

If you have Windows 10, you can always try the built-in screen recorder. I'be never heard anyone actually suggest it, though, so I'm sure it isn't better than the other free alternatives. As for editors, I use VideoPad. It ain't free (I paid $80), but there is very little in the free department besides those that offer basic cutting and splicing. But do try a basic free program first, to see if you're really interested in dropping cash on this sort of thing.

I believe people have tried the invisible point mass before and the result was spectacular game breakage. Or was that when trying to make a double planet? No matter; the same problems arise. You may want to take a look at the mod Principia. It's still WIP, but it adds N-body gravitation.

I'm looking into building a "starter" PC with my son, so I'm looking at ways to save money while at the same time "future-proofing" the build by choosing a mobo with an LGA 1151 socket. The low end of the processor line for that socket is a Core i5-6400 (which should be no slouch in the processing department), and is advertised as having "integrated graphics HD 530". I'm used to "integrated graphics" meaning a graphics chipset on the motherboard, not a feature of the processor (but then again, I haven't built a system in nearly five years). Does this mean we can save money by using a mobo such as this one which has no on-board graphics, just apparently a pass-through of some kind? I'll note that Toms Hardware rates Integrated HD 530 at roughly the same "value" as the GeForce 9800 GTX+ I'm using in my machine right now, so I don't think I'd be holding him back too much by not spending another $100 or more on a dedicated graphics card if we can get away with it. All the motherboards I'm considering have PCIe x16 3.0 slots so we can add one later. Of course, similar motherboards that do have on-board graphics are only $10 or $15 more than this one, so I'm less concerned about validating one particular super-inexpensive board than I am about making sure I don't get one that won't work without a bunch of extra expense. But if I'm not careful $10 or $15 here and there starts to look like an additional $100 real quick for the whole system..

I'd support simple life support such as Snacks!, or a little more flexible like USILS, but I'll say it yet again - we need mission planning tools built into the game, starting with TWR/dV info and ending with detailed long-term maneuver planning - before it should be implemented. We're already lacking this when all we need to worry about is fuel requirements - adding LS adds a time requirement, and will result in a lot of dead Kerbals because there's no real concept of time as a resource in the game right now.

Well, for starters, a craft that is capable of maintaining hover indefinitely, which for large constructions (such as magic flying landing platforms) is no mean feat. But looking beyond, you know, physics and reality, there are only a couple of cases (landed/splashed down) where time warp is allowed while the vessel is under load, and since you can ISRU, the mass of the vessel is allowed to change. It's conceivable you could trat it in the same manner as landed, but we do have the problem of the "ground" (jet) reactions changing as the mass changes, which changes the rate of change of mass, which is a little more complicated than true ground reactions. But not insurmountable. But the biggest thing you would need would be a compelling reason for the developers to add and support such a special case. I don't see a very large market for skyhooks, especially given the design difficulty I noted above.

What's wrong with the Ethernet on your PC? Getting that fixed is going to be far better use of your time than trying to pass files, especially with a DVD. A USB wireless or Ethernet adapter can be gotten for less than $30. If your current card is really kaput.

In one of the pre-release threads it was noted that the changes to some constants, "big G" in particular, were causing changes to geosynchronous orbits, and potentially changing the orbital parameters or masses of the celestial bodies as well: Is the effect of this change fully understood yet? I've created an orrery tool in Excel called KOMET to help me with mission planning, and if the GM or orbital parameters of the bodies have changed, I'm going to have to update all the values and re-compute the orbits before I release it. It would be a shame to be using obsolete data. I used the wiki to get the data I have now, but I don't know if it's been updated yet to reflect the new parameters - if they've changed at all. Is there a way for me to extract planetary orbits from the game somehow?

Click the "x of y downloads completed" on the bottom of the screen to bring up the download manager, and make sure there isn't something else holding it up.

What is the equation you're seeing without that factor? Does it include a term for damping?

Hansen's Diet Tanerine and Lime sodapop. And if there's chocolate in the house, it will join in along with an extra blast of insulin. But I only on weekends - during the week, just water.

The key in real life is engineers can design the airfoil of a canard such that it will stall before the main wing does, with high confidence. At the angles real wings stall at, the moment from stall drag is minimal compared to that from main wing lift. We don't have that ability in KSP. Airfoils largely have the same generic properties, and stall behavior is generally nothing to be particularly impressed with. The main reasons we don't see them in more use in real life are probably because a) the chief advantage - that all wing surfaces provide lift rather than downforce - isn't that advantageous with all the other design options we have at our disposal. Also, b) we understand very well and are used to wing-tailplane designs, which are practically demanded by single-engine tractor-propeller designs, which were easier to deal with in the early days of the industry. "Pusher" designs, which call for canards more often, demand multiple engines or (for single engines) more structurally complex or multiple tails. And "design inertia" is a very difficult phenomenon to overcome. Fewer major design changes (like the lift paradigm) result in cheaper design and engineering costs. Which is probably why rear-engine jetliners use T-tails, even though canard configurations are possible with them. In KSP, we use canards often because we don't have the same kind of fine control over fuel location (CoM) or wing design (lift/stall) that real engineers do.

My six-year-old wants to be a toilet. His four-year-old brother wants to be a bat. He insisted that I be one too. …so I'm going to find some big tubes and go as a Louisville Slugger.

The whole point of the nose-cone core was to allow a Scientist or Engineer to act like a pilot; the loss of functionality is definitely a 1.2 thing. You should post this in the 1.2pre subforum so the devs see it while they can still address it before release - it's a special case that apparently got overlooked in the communication overhaul.

It doesn't need to even be as coarse as 45 degrees - being keyed at the small rotation angle of the build scene (what is it - 1/40 of a rotation, or 10 steps per 90 degrees?) would be close enough to force two units into the correct alignment most of the time. Getting two units almost aligned isn't the hard part - it's the final few degrees or tenths where the trouble is.

The A380 doesn't look too awkward from a ways off. …but the Beluga is made from an A300, and you'd know it if you saw it.

Do we really have such terms in real life for All the moons? I was under the impression that we only really used -helion, -gee, and -cynthion very much. (and I swear I saw -selene used rather than -cynthion once. Might have been when reading Lost Moon)

Cool! My company makes components for 3 of those.