Zeiss Ikon

Mkay. We shall use science to demonstrate that it's a device for separating potential backers from their money. Yes, that's correct. The magazine cover associated with it strongly suggested the magazine's editors didn't know their basic science, however; it showed flying platforms and such in a futuristic city, all supposedly based on this "impulse-impact" drive. Let's also not forget the (fictional) "skyhook" drive from Lee Corey's Star Driver. Based on the idea that F=MA only holds if A is small enough, it used a tube full of low pressure neon inside a coil; the neon was ionized and shuffled back and forth by the magnetic fields, turnaround sharp at one end and soft and gentle at the other. A sort of molecular Dean Drive, if you will.

Okay, seems to me I've read about that, pretty recently (1.3.0 or 1.3.1) too. My instance may have been an extension of another issue I have from time to time where I'll lose the ability to click in my orbit and get a dialog for "Add Maneuver" and "Warp Here" or "Warp to Next Maneuver" -- switching to Tracking Station and back usually fixes that one, but that loses me the "revert" button on the pause menu.

Not about science, either. It violates conservation laws, if it provides any net impulse. There was a scheme similar to this before WWII -- I've read an article in Popular Mechanics from them; they called it an "impulse-impact" system. Two weights propelled outward from a center (zero net impulse) strike a spring on one end, a plate on the other; the bounce back from the spring produced twice the impulse as the slap on the plate, moving the whole thing forward. Once. If you install a mechanism to reset it, it'll use up the momentum imparted by the spring when it resets the unsprung mass. Same thing here. And using enough energy to melt the metal ball means you're also throwing away a lot of radiated heat (and the electric energy required to produce it). EM drive might still have an EM exhaust of some kind, effectively using something akin to light pressure to produced (minuscule) thrust. This thing cannot produce any net thrust in any direction (that's not accounted for by wasted heat radiation).

I've never run the game on any OS other than Ubuntu (Kubuntu 14.04.5 LTS, and Ubuntu Mate 16.04.3 LTS, nVidia GTx750 with nVidia's drivers on the desktop, Intel 945 on the laptop). I've never seen the menu issues mentioned above in 1.3.0 (I started with 1.2.2 and haven't installed 1.3.1, nor yet 1.4). I downloaded direct from the KSP web site, however, rather than through Steam. I run at multiple resolutions from time to time as well, both on my old monitor (1280x1024), my laptop (1330x720?), and on my "new" desktop monitor, 1920x1080. I routinely switch from a window to full screen on my desktop machine. Have you checked your video drivers?

I had to complete several Mun "explore" missions before getting my first "Minmus flyby" in my current (1.3.0) career. I suspect this is the common theme; it takes significantly more dV to get to Minmus than to the Mun (though a landing and return is actually cheaper at Minmus, because its own gravity well is so much shallower than the Mun's), and the contract system is set up to give you time to develop slightly more advanced rockets before it starts to send you there.

To clarify, I was using the "generic you" in my original reply (first reply in this thread). Not speaking to @DoctorDavinci specifically, just "you" as in "all of you." Unless you've managed to avoid seeing a news headline in the past, oh, six or seven years, you must surely know that your TV, phone, and possibly your household appliances (refrigerators, microwaves, maybe even toasters) are capable of spying on you. Are you really so concerned about a game? If there's anything in KSP that qualifies as malware, it'll pretty shortly show up in whatever scanner you choose to use. Fairly probably, it will, even if there's not (because malware scanners have been producing false positives since at least the early 1990s -- before the word "malware" was in common use). And give the responses from someone obviously partly intending to break stereotype (a confrontational, marginally rude Canadian?!), I'm done with this thread.

Seems to me the EULA I read just a couple days ago constituted all the warning anyone should need that the game may send data that's not personally identifiable back to the publisher. Then again, if you live in today's world and there's anything you expect not to do that, you may want to reassess your expectations.

The first I've heard of it was in 1.3.0 or 1.3.1 -- but then, 1.2.2 was current when I started playing. I've seen a couple "help" threads fairly recently with that problem, and had it happen to me (1.3.0, 64-bit, Linux) at the end of a long session, though mine was resolved by closing the game and reopening the next day.

I'd venture to say that every one one of us has stranded a Kerbal coming back from the Mun on at least one occasion. I once stranded one in Munar orbit, ran out of fuel in the rescue craft trying to rendezvous (and ran the stranded Kerbal's suit jets dry), and then ran the next rescue craft (with my last pilot) out of fuel trying to rendezvous to rescue both of them. That was close to a year and a half ago; now, after some dozen hours or so of YouTube videos and several hundred hours in game I can usually rendezvous and dock (from a reasonably close orbit) with just a few units of Lf/O and a dozen or so of monopropellant for the RCS and I can EVA transfer a Kerbal across 20-30 m in less than ten minutes (real time), usually hitting the hatch so I get (B) to board before (F) to grab. Keep at it, I might be learning from you in another year.

I probably won't get it first day out (three days before payday), but I'll get it. Two-Kerbal command pods and all the other historic-ish stuff -- I don't even really care about the mission editor.

Wow, that's a really major achievement. Every time NASA splashed in the Pacific, it was west of South America.

I understand this to be a known bug that appeared in version 1.3. There are a couple known fixes that I've seen in other threads, though I'm not confident of my ability to convey them (in general, they involve editing your persistence file, which is hazardous -- make a backup copy first, as an error can render the save impossible to load). If you haven't done it yet, the first thing to try is closing the game, restarting your computer, and relaunching the game. This has been known to resolve the issue, though it doesn't always.

I can't begin to imagine playing this game without reverts and saves. Going to the Mun before you have patched conics, and without reverts or saves? Good grief!

That part is also called a "shroud". Fastening struts to it is completely useless (in fact, in my experience, the strut will either refuse to attach (looks like it's just the base end without the attachment and second end) or will auto-jump to the tank just above the shroud. The former is most likely if you've had the strut on, then removed and replaced the booster/tank with the base end of the strut. Reset those struts so they connect to the second stage tank and they'll do much more to stiffen your stage joint.

This is far from a maximum performance capacitor. Capacitance increases as the plates get closer together, providing your dielectric doesn't break down and permit an arc. Vacuum (at least the imperfect kind you find close to planets) is, relatively speaking, a terrible dielectric (ultra-pure water is better, just as an example); you need far too much distance between plates to prevent arcing in order to get maximum electric field density (which is where the energy is stored in a capacitor). if you're doing something that needs maximum capacitance, you'll usually select/fabricate your capacitor to have the biggest plate area possible, the least separation between plates you can manage (i.e. thinnest dielectric) and still isolate your working voltage, and in some cases, the lowest self-inductance possible (don't roll the thing up, let it lay flat instead). Leyden jars can run to extremely high voltages (tens or hundreds of thousands of volts) because glass has a very high breakdown voltage -- but the glass in common jars is too thick, limiting the charge they can store. If you're building a TEA laser, you'll usually fabricate your capacitor(s) from foil plates lying flat with food wrap or projection transparency sheets, and live with a limiting voltage between 10k and 25k (both of those dielectrics will break down after a time even at 10kV, and they'll break down quickly at 30 kV). The dielectric choice here is a compromise; thinness improves capacitance and reduces self-induction, and the thing is easy enough to dismantle and rebuild that a short working life is an acceptable tradeoff. This kind of capacitor doesn't store huge amounts of energy, however; it's optimized for voltage and charge/discharge rates (the foil/acetate type used for TEA lasers can charge and discharge between ~0V and 10kV 120 times per second if the power supply is up to it).

The OP already posted the log window that this brings up.

I'm going to join others in pointing to the Strut Connector colliding with the tank being the first failure. Assuming the 7200 tank is the second stage tank/structure, I think one of your boosters is shifting inward, destroying the second stage tank, which then allows everything else to collapse in a fraction of a second (all those failures are listed at 9 seconds MET). Checking your staging is a sensible thing in any failure analysis, but in this case, I suspect you have struts that weren't applied in symmetry (even though the SRBs presumably were), leading to at least one that didn't get connected correctly; your nine seconds is the point at which something (likely aero forces) adds up enough to let the decoupler flex the strut connector into the tank.

Yes. Fluid Dynamics does not coexist well with the desire for an exact mathematical description. Numeric methods are the rule, even at the theoretical end -- which is why Computational Fluid Dynamics is such a big deal (and why most of the supercomputers that aren't doing weather or crypto-stuff are doing aerodynamics).

I've seen a post about a "monorail" from KSC to the island airport; as I recall, it was made with tweakscaled fuel tanks or fuel fuselages, supported periodically by pylons (standing on the bottom of the ocean!), and traversed by a train. Yes, it required mods, but no, as I recall it didn't give any trouble with physics range -- and that's well over 50 km, as I recall.

There's a setting for that in Science mode -- you can choose whether your buildings start off upgraded or not, and whether your Kerbals start off with no stars, or five. It's not clear to me how you'd upgrade the buildings in Science, however, since it doesn't keep track of funds. So, start a Science save, set to "not upgraded", and then use the "cheat" menu to unlock the tech tree.

If we count only HOTOL, I've gotten as high as 40 km, on a flight that went halfway around Kerbin. If we included vertical launch, I used a spaceplane orbiter for LKO and Munar flyby tourist missions; even attempted a Mun landing (aborted due to low fuel). Of course, I've really only designed/built spaceplanes in my current career.

Yep, I've seen a Mark 1-2 with a single Kerbal aboard pull 5 G reentering from the Mun with a 35 km perapsis -- and that acceleration will be close to 30 km up (but the command pod is still traveling at or slightly above circular velocity for an 80 km orbit). Don't forget your heat shield! That energy has to go somewhere...

I'll echo what everyone else here has been saying. Kerbal Space Program is not an easy game to master. That's what makes it a game you can play literally for years. I've been playing for a year and a half (no hour count, since I don't play on Steam, but I'd guess that's several hundred hours, since I manage at least a couple hours a week). In that time, in four different saves (two sandbox, one science, and one career), I've landed repeatedly on Mun and Minmus, performed many rendezvous and docking, flown past Duna/Ike, and landed on Gilly. I knew more about space flight than most folks when I started; I've been a space enthusiast since Gemini was a current program (so, yes, I'm old, too). It still took me a while to get the hang of launching to an orbit, launching efficiently, managing rendezvous, and the first time I docked it took me over an hour real time (first time I tried to EVA a Kerbal, I had to load a save after losing them too far away to see the spacecraft they were trying to board). The day will come when I'll land on Duna, visit Dres, and tour the Joolian moons. At some point, I'll probably install a mod to get more planets, play in rescaled (larger planets, more distance between), add a life support mod (so Kerbals can't just spend years drifting in their space suits, waiting for rescue) -- there's no end to this game. You're just getting well started. Learning is what makes it fun.

ICBMs are also much "harder" -- they already have a reentry vehicle (RV) that can handle diving deep into atmosphere, reaching low altitudes while still at near-orbital velocity. If you're passing through 20 km altitude at 5-6 km/s, a tungsten cube at near-zero velocity might not even penetrate the RV heat shield. The nukes mounted on Zeus missiles were intended to "pre-react" the pits in the incoming nukes, preventing them from detonating on command by sharply reducing the quality of the bomb metal. IOW, the shrapnel they spread (that mattered) was neutrons, and the damage done to the incoming warhead was on a subatomic level. This strategy was used on ABM designs at least as late as the MX, and the "dense pack" strategy of the Reagan era amounted to letting enemy warheads do the same to each other (on the assumption that a time-on-target or MIRV attack on a dense pack site would bring the incoming warheads close enough together to damage each other or at least upset their targeting, too late in flight to correct). Some newer systems used in ABM roles do rely on either direct impact, kinetic kill (like the flying windmill pictured above), or on "shotgun" or shrapnel strategies. Based on my reading, these strategies are aimed primarily at IRBM and battlefield missiles (like Patriot against a Scud, or a point defense system against a smaller, shorter-range missile). ICBMs are still too high and too fast, too hard to detect in coast phase, too far away during boost, so the strategy, left from the Eisenhower era (at least in part, because development takes decades) is still to nuke ourselves, high enough to do little ground damage, in order to mission-kill incoming warheads.

I'm surprised no one has mentioned Better Burn Time. It's a tiny mod, which puts virtually no load on your system (a tiny display overriding the stock burn time display, and a little background math,which CPUs are really good at and which can, in theory, run on a different core/thread than the physics engine, though I don't know if it's coded that way), and when you're within 120 seconds of impact, displays a running count of time to impact, estimated burn time to zero velocity (total vector velocity, not just horizontal or vertical) and a very intuitive countdown to start the burn. It also does the same for maneuver nodes, rendezvous, and reentry/atmosphere exit when your orbit intersects atmosphere. For suicide burns, the only real flaw in BBT is that it doesn't take into account your deceleration in calculating time to impact -- which means, if you start your burn when the countdown reaches zero, you'll stop well above surface. This is a design decision; the alternative, to assume you'll start burning at countdown time and calculate from max thrust, is too sensitive to variations in terrain (for which, as far as I can tell, BBT uses vertical altitude from the vessel, essentially what you'd get from a radar altimeter -- and if you have significant horizontal velocity, though the velocity vector is correctly accounted for, changes in terrain height can't be predicted). Now, for an optimum landing burn, you want to land SpaceX style: reach a non-zero vertical velocity and non-zero lander tilt, with non-zero horizontal velocity, both within parameters for the landing legs (not to collapse, not to tip the lander), and run out of fuel just as you'd otherwise cut off for touchdown. This has been coined as a "hoverslam" -- that is, if your legs can take, say, 14 m/s impact you'd like to land at 13 m/s, +- 1 m/s; if your lander can handle 2 m/s horizontal, you want to land as close to that figure as possible -- and then have your fuel calculated so you land with none. Perfection of this computer-controlled operation (well, near-perfection, as demonstrated by the Falcon Heavy central core running short of ignition hypergols to relight three engines for landing burn) is what allows SpaceX to launch commercial/government payloads and recover their boosters -- it allows minimizing the fuel that must be reserved for boost back, reentry, and landing burns. Every kilo of fuel left in the tanks at landing burn shutdown requires more kilos to lift, reverse, reenter, and land it, so zero is the ideal number -- and the higher your landing velocity (short of breaking stuff) the less fuel you need to brake to that figure.