Zeiss Ikon

Add one more tank and a suitable set of fins (I made mine from, IIRC, Delta Wing B and Elevon 1, the latter moved inward to give the correct projection at the tip), switch out the Swivel for a Reliant (mostly moved up inside the bottom tank), and you'll have a rocket that strongly resembles the Mercury Redstone -- except that, even with the bottom tank emptied, it'll almost make orbit (might well make it and strand Jeb, if I'd remembered to dump the monopropellant and shave down or delete the heat shield, and flown just a little more aggressive gravity turn). Too bad Making History didn't give us a Launch Escape System scaled for the Mk. 1 Command Pod.

Coming back from orbit is actually better than suborbital for this situation. When deorbiting, you have a lot of velocity high up, which gets you useful amounts of drag at 40-55 km. When coming back from a barely suborbital jaunt, you won't get useful drag until you're below 30 km (in my tests yesterday, I wasn't getting plasma -- which is based on both air density and speed -- until just above 25 km). This is why you get much higher G forces during reentry from a near-vertical suborbital launch than you do coming back from the Mun or Minmus, unless you set your Pe much too low. Valiant didn't mention fins (with a Swivel, using just heading hold would easily allow flying to orbit without them) -- if you try to reenter with fins (i.e. nose-first stable), there's no way you'll be able to hold retrograde after you hit air, and then there's no chance you'll be subsonic before impact. BTW, I was incorrect in one of the quoted points above. I went back and looked, and the Swivel doesn't weigh almost as much as the Mk. 1 Command Pod -- it weighs more than twice as much. The combination of lower drag than the blunt base of a pod, with roughly four times the mass (including empty tanks, along with the pod and engine -- any science attached will make this still worse) and you get a craft that is extremely trajectory critical in terms of being able to slow down enough to deploy parachutes without a retro burn. BTW, @magnemoe two Mk. 1 Passenger cabins and the 1.25 equipment bay, plus four more Kerbals, still weigh less than a Swivel, I think.

No, an inclined orbit doesn't "slow down" in terms of orbital velocity, but the velocity vector (relative to the surface) turns eastward near the inclination limits, so the north-south component is reduced. In the limit (that moment when the satellite is exactly as far north or south as it will ever get) the north-south velocity is zero, just as it would be with a pendulum at the end of its swing. In fact, the north-south component of a satellite's ground track is a better approximation to true "simple harmonic motion" than a pendulum. Straighten out the ground track (that is, map it to a flat projection) and assuming the eccentricity is low (a good assumption in this case, since orbital decay tends to reduce eccentricity -- the drag impulse applied near periapsis lowers apoasis preferentially), the plot will be a sine wave, which is also the displacement/time plot of a system in true simple harmonic motion (characterized by a linear restoring force). In the simple case of a circular orbit, the north-south component is simple harmonic motion. I keep coming back to sine waves and simple harmonic motion because you can easily see, in the plot of a sine wave, that the half of the time centered on the peaks of the waves has much lower slope (analogous to north-south velocity in an orbit plot) than the half centered on the zero crossings. Those peaks, with their reduced slope, show how an inclined circular orbit spends more time near the north and south limits than in a similar distance from the equator -- because the limits are approached with north-south velocity dropping to zero, while the crossing are approached with north-south velocity approaching its maximum value. This is why any given square kilometer near 42.7 degrees north or south is at greater risk than a square kilometer near the equator.

If you drank enough Scotch to treat a urinary tract infection, it's no wonder your rocket was tumbling...

I've got the situation in my current (and only) career where on almost every launch, I see at least one piece of debris come within 100 km of the craft I'm actually flying. Occasionally, I've had them come withing 30 km (close enough for an actual name display when I point to the little bracket on the screen). I consider this hazardous, mainly because if I'm ever going to collide with one of these, there'll be effectively no warning unless I happen to be looking toward it as it approaches, and the only way to avoid it even if I spot it is to make a sudden, unplanned burn (bad for dV budgets, might create an unplanned reentry, etc.). Since I noted this, I've adopted a policy of avoiding creation of debris when possible. I've got a reliable launcher that will lift craft the mass I'm using most (for the present) almost into LKO, so I finish circularizing with the transfer/service stage, and the booster burns up or crashes/splashes. Then on return from the Mun or Minmus, I can easily ensure the service stage is dropped into the atmosphere, where it burns up or (a part or two) crashes. I can't yet do much with modules left over from rescues or debris already in orbit; I think I'm going to have to go ahead and research the Klaw next time I have a batch of science, and adopt a harder policy to capture and deorbit anything that can be reached without jeopardizing the primary mission -- or launch a mission every now and then that has no goal other than to capture and deorbit as much debris as they have dV to reach. @Mark Kerbin Even though the odds are against a collision, even with your level of debris, it only takes one collision coming out of nowhere to undo hours of design, construction, and testing, possibly also bollixing a contract that winds up costing tens of thousands of and a bunch of prestige.

You're very welcome. I've never built or flown a propeller; the only reason I knew to suggest that was because I watched a video recently on how they're built. All the ones that use reaction wheels for power will have the same issue. Turboprops (which use a jet engine blowing against the rotating part to push it around, but still have the same rotation mechanism) require changing craft only if you need to adjust the pitch (if the propeller is made from a movable surface like an elevon, this is possible, but not recommended for reaction wheel propellers because you'll be changing both power and pitch with the same control).

I just tested this exact situation in my 1.4.1/MH sandbox -- Mk. 1 command pod, Mk. 16 parachute, 4 FL-T100 tanks, and a Swivel. No decoupler, no heat shield, monopropellant drained from the pod. If I burned all my fuel and finished with a 45 degree climb, the rocket would in fact slow enough to deploy the parachute before hitting the water, but only just; first deployment was below 10 km, and final deployment was still at 250+ m/s, finishing deceleration barely 200 m above the water. This rocket, however, wouldn't leave the atmosphere. If I built the rocket with six tanks, it would leave the atmosphere with a 45 degree final climb, but wouldn't slow enough to fully deploy the parachute before impact. If I saved approximately 20% of the fuel (100-120 units), I still cleared the atmosphere for close to two minutes, and was able to make a burn at 10 km to permit parachute deployment, and another just above 2 km prevented shredding the parachute from excessive speed. Alternately, if the parachute was "destroyed by heat and aerodynamic forces", I had just about enough fuel left to slow the rocket before splashdown and let the engine and one or two tanks act as crush zones to keep the pod (and Jeb) intact. I don't recall this as being different from 1.3.0 or 1.2.2 (first version I played). These rockets are barely recoverable before you get decouplers, at least. OTOH, it's not too hard to get the science you need to unlock decouplers without even launching a rocket -- "pad science" and a short hike into another microbiome or two (crawler track, KSP lawns) with surface samples can get you enough science to unlock decouplers; you won't need a heat shield until you go beyond LKO.

@Valiant If you're reentering with your engine and tank still attached, you won't slow down anything like as rapidly as you would with just the command pod, with or without a heat shield -- you have much more mass (the Swivel weighs almost as much as the Mk. 1 pod), lower drag (engine shape vs. blunt heat shield or pod base) -- the only viable reentry with the full vehicle at minimum tech is to keep enough fuel to slow down for parachute deployment, then make another burn just before splashdown if you want to avoid using the engine and tanks as explosive shock absorbers.

After you decouple, the airplane and propeller/engine are two different craft. Press [ or ] to switch focus to the "craft" that is the propeller engine, then use Alt + E to set your roll trim, which acts as the throttle for the engine. Then press the opposite bracket key to switch back to your airplane proper to fly. You have to do this every time you want to change the throttle setting -- and once for each engine if you have a multi-prop craft.

K. What I get for not reading current literature in a field I'm not active in... My own suspicion is that they'll eventually find that all mantle plumes detectable via hot spots will prove to be deep. Then again, I'm not a geologist, never mind a geophysicist. Nor am I likely to live long enough for that argument to be resolved (I'm old enough to remember when "continental drift" was a crackpot hypothesis and the outline fit between Africa and South America was just a coincidence -- wrote a 6th grade paper on "isostasy" and found some of the early suggestions about what became plate tectonics in my research). I will say that I consider the idea of trying to drill into the Yellowstone magma plume, for any reason, to be a very, very, VERY bad idea. Sort of like, "we think this might be a WWII anti-ship mine, let's drill some holes in the casing and see" bad. I think the resources of humanity are likely better spent in establishing colonies off Earth, before either we or the geology we live on can render Earth uninhabitable (even on a geologically temporary basis).

@Tokoshoran If you have SAS off, you want pretty slow rotation, because you'll have to stop the rotation manually. That said, I usually don't have trouble with too much authority, even when I add a second, large reaction wheel to my launcher in addition to the built-in one in the Mk. 1-2 or Mk. 1-3. Even after staging away the booster, and with only the service and command stage, there's hardly any such thing as too much pitch or yaw authority. Then again, I use the SAS holds a lot when I'm in orbit. Even if I only have prograde and retrograde (as is the case in the early game -- once your pilot's been to orbit, that is), they're the main ones I need (I use them to get a close point near my maneuver node, even if it won't be on one of those directions when burn time comes up -- faster and easier to adjust from a hold point than rotate through 150 degrees manually).

One of the earmarks of a hot spot is vulcanism that holds position even as tectonic plates slide past. Hawaii (the volcano chain runs hundreds of kilometers out to sea in the form of seamounts that have eroded to below wave level -- and even shows a distinct bend, where the drift direction of the East Pacific plate changed by 15 degrees or so some millions of years ago; the chain ends where it subducts beneath the East Asian plate), Kilimanjaro and the Virunga region of Africa (Virunga is on the northern edge of the Congo drainage, west of Kilimanjaro), Yellowstone and the Southern Idaho lava fields (all from the same hot spot, going back 75 million years). Not all hot spots have supervolcanoes; not all supervolcanos are over hot spots. There's some reason to believe that all hot spots are fed by deep mantle plumes (potentially rooted in the outer core); not many other features could remain in place over the time scales hot spots demonstrate, nor supply the energy to repeatedly and continuously burn through hundreds of kilometers of continental crust in the thickened areas near a compression feature like the Rockies.

In terms of risk, there's a great deal of difference between living in a village or town close to the Chinese launch site (which puts you under the falling boosters for every launch, meaning your risk of getting one on your house is like living on a target face at a shooting range), and living anywhere between 42.7 North and 42.7 South during the uncontrolled deorbit. FWIW, though, the article I read was correct that there's a slightly increased risk of the impact falling close to the limits vs. anywhere else in that belt because Tiangong 1 spends proportionally more of its orbit time close to the "turnaround points" at the northern or southern parts of the orbit than it does near the equator. For an illustration of how this works, look at the motion of a pendulum bob -- it passes center at maximum velocity, but it slows way down at the ends of the arc, and spends more time (per millimeter of arc length) near the ends than in the middle. That means the least likely place for Tiangong 1 to land is close to the equator; the most likely is close to the northern or southern limits of the orbital ground path. Conversely, Oregon takes up a tiny fraction of the land under the northern limit, and the bulk of the state is too far north anyway (the 45th parallel runs through the northern part of the state; that's 2.3 degrees, or almost 140 miles (225 km) outside the orbital path coverage). Statistically, the station is more likely to hit Colorado (100% within the path and similar area to Oregon), California (further south, but 2-3 times the area), Arizona, New Mexico, or Texas (same or a bit further south on average than California, but even larger). I live in North Carolina; we're 100% within the area at risk, but significantly further south than Colorado and much smaller area than Colorado or Oregon. Honestly, China probably has the highest risk here; most of their country is under the path, and that's much more land area than the portion of the US at risk. Brazil, India, and nearly all of Africa are at risk, too -- and more than half of the population of Oregon lives near Portland, too far north for concern.

@Streetwind I'm pretty sure you did it right, Tokoshoran's quoting made it look (if you didn't read carefully) like you were pointing that comment to him.

@Tokoshoran Streetwind wasn't calling you out, he was replying to 90VG, and pointing out to you that 90VG was using an old, old method (which was required in pre-1.0 versions because the atmosphere was basically soup until 10-15 km, so you had to launch vertically until you were out of the soup). Some of the older tutorials on YouTube use that technique, and it still works with a sufficiently overbuilt rocket, but with the current atmosphere, you do much better to start your gravity turn at or before 100 m/s (usually reached around 1 km), set the angle you know (from prior "simulation" or experience) that you need, and then set prograde hold and just watch the rocket until it's time to stage or shutdown for your coast to Ap and circuclarizing burn (in fact, done perfectly, there is no circularizing burn; you'll shut down at orbital altitude in a very nearly circular orbit). I've got a rocket I use in the mid-game that flies like the training rocket; it uses a Twin Boar with a 6400 tank on top, large inline guidance unit (reaction wheel), a battery or two, decoupler, and up to 15 T of anything on top. Flown even halfway well, you'll get LKO with enough dV left to deorbit the whole stack (there's also a version with more batteries and a probe core, with a dozen parachutes and six landing legs mounted for horizontal landing; it'll orbit more than 13T, decouple and deorbit itself and land back undamaged on not-too-steep land or water). It's cheap, low parts count, and pretty efficient for a rocket launcher (as opposed to a HOTOL spaceplane that will have three times the parts count and five or six times the up front cost to carry the same payload, but might burn less fuel).

I upgraded my existing career when I switched to 1.4/1.4.1/MH, so I can't say if this is new behavior, but as you said, it seemed the contracts came in a sensible order in 1.3.0 (the first version in which I played a career). I haven't seen any out-of-sequence contracts since upgrading, but I've only accepted one batch of contracts (standard fare, tourists to LKO and Mun landing, a rescue, and the first landing on Minmus) since my upgrade.

For whatever it's worth, if you're on Windows, you can still find IE as old as v. 6 online (I run Ubuntu, but I know, because PlayOnLinux and Winetricks both can install versions that old on demand). I'd be cautious about using them for everyday use (versions older than about 10 aren't supported with security updates any more), but if you really need an old browser that can use Unity Web Player, I bet IE 7 or 8 will do the job. Now, finding Unity Web Player itself, to install, may be a bit trickier...

Backups, man, backups!

I was never a Unity fan. I started with KDE (chosen for its visual and functional similarity to Windows 95/98/XP Classic) on MEPIS 11 (another Debian offshoot) back in 2011, then switched to Kubuntu 14.04 in 2014. Couldn't stand the cube, though, and I've never taken to "workspaces." Might be just because I'm a round ten years your senior, and that much more set in my ways...

Looks like I didn't check the thread for too long -- I see you've got your Ubuntu installed and DTE switched already. I was going to suggest Ubuntu Mate, which is what I run on my desktop and laptop. Mate is a fork of Gnome 2, and I prefer it over Gnome 3. It's actually got me looking forward to 18.04 (usually, I hate upgrades, because they break more stuff than they fix). I used to use KDE 4, but when Ubuntu 16.04 (and everyone else, due to KDE support limits) switched to KDE 5, it abandoned most of the eye candy that made me like the system. If I can't have Keramik window theme, what's the point of running KDE at all?

Most likely, it's what's called a "false positive." Virus detection depends on looking for "signatures" -- little bits of code, small enough to search efficiently, and reasonably unique to a particular routine used in (hopefully) a number of different malware packages. Depending on the choice of signature, however, it may turn out to be library code -- that is, reusable code snippets that are supplied by a programming tool or environment -- rather than anything actually specific to malware. Further, even non-library code can sometimes be similar to code used in malware, because legitimate software needs to do most of the same things malware does, just not in the same order or manner. Copy files, communicate over the network, be flexible in network detection, even encrypting files (a common operation for ransomware) is a completely legitimate operation (say you want to send something and don't want anyone who intercepts the message to be able to read it...). Given that everything malware does is also a legitimate operation under different intent or circumstances, it's not rare for software (in my experience, especially installers) to give false positives in malware detection scans. It does, however, complicate life, especially since some well publicized incidents where large software publishers inadvertently distributed large numbers of their software packages in which some modules were infected with malware. Is that really a false positive, or did Squad/Private Division actually send out infected software, presumably without intending to? The only way to be sure is watch for the reports of others. I've seen a number of reports of updated definitions eliminating the warning about files in the KSP/MH packages being infected with Windows malware, which tends to suggest that the report was a false positive in the first place. Since I run Ubuntu, it didn't bother me anyway -- you can drop all the Windows malware you want on my system, it won't run (not to say there isn't Linux malware, but virtually all of it is aimed at servers and doesn't do anything significant on a desktop machine).

I'm not aware of any real-world crewed spacecraft that have actual reaction wheels. Space telescopes tend to have them, because they can be used to manage pointing for rather long periods without burning RCS fuel continually (occasional observation shutdowns are required, so the RCS and desaturate the reaction wheels). You might recall Kepler's primary mission ended when a reaction wheel failure meant it could no longer be precisely targeted on its primary field for long periods, and Hubble has required at least one repair mission to replace reaction wheels that were approaching failure (bearings were failing, as I recall). As noted above, however, real life reaction wheels don't have the power needed for routine maneuvering, and because the flywheels have RPM limits, they can "saturate" -- that is, when the wheel can't turn any faster, it can't apply/absorb any more angular momentum in that direction. All the stuff that goes with rapidly accelerating and decelerating heavy rotating objects applies to reaction wheels, not to mention if something goes very wrong, a wheel can fail (and a failure of a massive wheel spinning at tens of thousands of RPM strongly resembles an explosion -- not something you want in the cockpit of your Space Shuttle). There are in-game reasons to include a wheel (system), as noted in other answers -- but if you want maximum realism for crewed craft, you'd have no reaction wheels at all (and be prepared to run out of monopropellant at an inopportune time).

Yeah, not so much. May as well reenter in a plastic milk jug.

I routinely reenter to 35 km Pe on a direct Mun return orbit. If you have a heat shield, it shouldn't be a problem, just turn SAS off when you get down to around 55 km altitude. The regular Mk. 16 parachute (fits the nose of the Mk. 1 command pod) is plenty for a Mk. 1 pod, but don't forget to jettison your heat shield after you get the parachute open; that'll make a difference of a couple m/s in your descent velocity.

I seldom had those problems with DOS. Maybe I was just lucky, but I don't recall ever having an IRQ conflict. My Sound Blaster required a jumper to be moved, and of course there were the master/slave/cable jumpers on MFM and RLL hard disks, but I never had much problem with those.