Zeiss Ikon

Thanks. Based on the turbo going up to 3.4 GHz, I presume the installed RAM is the correct spec 1600 MHz. Still have to open the cover to see if it's a single 8 GB stick, or two 4 GB sticks. Fortunately, even laptop RAM isn't all that expensive these days.

Well, for what it's worth, my laptop gets intermittent yellow clock on a vessel in space with 30 parts. It's only with spaceplanes that I've noticed the other bit, and still haven't isolated whether it's GPU, CPU, RAM, or thermal limits.

I haven't even opened the RAM cover on my Thinkpad. It's held with screws, of course, and it's under the Slice battery, so I'll have to find a time when I can spend twenty minutes or so to open it up and check if a) there are any free slots, or b) the RAM is dual channel (most is, if it's fully populated). Longer term, I'd like to switch out the HDD for an SSD -- it made a tremendous difference in overall system performance on my desktop machine -- but I don't see it affecting KSP much, because most of what the game is doing ought to be in RAM, except when I have to load something coming into view or physics range. If it's a single DIMM, the obvious answer is to double up -- both for the video boost for integrated graphics, and just because more RAM is always worth having. For whoever asked above somewhere, I've been running 64-bit for everything possible since I first installed MEPIS 11 six years ago. Not very coincidentally, that was about the time the Linux kernel started providing really decent support for multiarch libraries. @Cpt Kerbalkrunch Over the course of two years, I owned no less than six Color Computers, ranging from a 16k chiclet key gray-case unit to a CoCo3 that I upgraded to 512k RAM (though I never had OS9 to make real use of that RAM). I used the original 64k chips out of that machine when I got my first DOS box (1987) to backfill the stock 512k to 640k. That machine, a Laser XT, eventually maxed out at 4.5 MB EMS, SVGA (512K, 1024x768), and dual hard disks, 30 and 40 MB -- and ran Windows 3 for a while in that configuration. Edit to add: Say, does anyone know of a GPU that can be mounted in a mini-PCIe slot? This Thinkpad should have one where it doesn't have a cellular broadband card installed, and it should be the longer form factor...

Well, of course, the other KSP problem is having time to play. I'll try to remember to run a couple tests (for CPU vs. GPU vs. RAM vs. heat bottlenecks) next time I can play. Based on the (perceived) periodic nature of the slowdowns, I'm suspecting RAM, via garbage collection. Why is it that every time you upgrade to "this should be enough RAM" it turns into "oh, you have *only* X GB?" OTOH, my conky reports I usually have multiple GB of RAM free, even when running KSP (and my only mod is Better Burn Time, which ought not to require much of the system). The computer was bought refurbished, but was very clean when it arrived a few weeks ago. Also, I have both temperature and clock speed monitor widgets running, so I can see core and MB temps in real time, and see when the system throttles the CPU. I also run MilkyWay@Home, which uses priority to stay out of the way of foreground tasks and uses little RAM, but it does run the CPU at 100%, which likely contributes to keeping the machine hot. BOINC (@Home manager) does have a setting to not run when particular other apps are in use, or when there's high demand, I may have to explore those settings. Unfortunately, the detailed CPU performance settings apparently no longer exist since introduction of the "p-state" drivers; reasonably current Core processor drivers have only two settings: "Performance" and "Power Saving", the latter is effectively "On Demand". I've set my preference to "Performance" (I very seldom play on battery, and my battery life has been excellent since upgrading batteries). Ubuntu MATE doesn't appear to have any detailed performance settings for the Intel GPU, but I recall this issue occurring more or less equally whether I'm looking out into space or at Kerbin from low orbit (or in atmosphere), so I doubt GPU is the bottleneck. I do run pretty modest graphics settings, out of long habit (seems I always have a computer that can just barely run whatever game I'm trying to play).

Okay, I asked this once in Tech Support, and got no response over several days. I then concluded that the issue was probably a performance setting on my computer, but it turned out I'm already optimized on that front. So I'll try again here. I'm running KSP 1.3.0 on Ubuntu MATE 16.04.3 LTS on my Thinkpad T430, with Core i7 (dual core, 2.9 GHz nominal, turbo up to 3.5 GHz), 8 GB RAM, platter hard disk, and on-board Intel graphics. I have more than 100 GB free space in the Ubuntu partition on the hard disk. I'm playing on AC power, and have the system's clock management set to "performance" (the only other alternative is "power saving", and changing this seems to have little effect, since both do on-demand clock management; "power saving" is just more aggressive in slowing down the cores when demand drops). What I've read says this computer should nicely outperform my desktop machine, Kubuntu 14.04.5 LTS (with alternative XFCE desktop installed), Core2Quad 2.7 GHz, 8 GB RAM, and SSD with ~50 GB free. My experience since installing KSP on the laptop contradicts this; overall performance is about the same. I'll get a yellow clock when flying any vessel with more than 20 or so parts. I've had the laptop since October. Over the past couple weeks, however, I've been running into serious lag. What used to be an intermittent yellow clock with a 20 part vessel is now a solid yellow clock, proceeding at close to half actual time rate, with the same vessel size. Worse, when flying an aerospace vessel (glide reentry orbiter or HOTOL spaceplane) I'll get near-freezes, where engine sounds continue to play and altimeter and velocity displays update, but there's no response to control inputs for several seconds. If this occurs at low altitude when attempting to land, it's prone to cause a crash, and if at high altitude, it can lead to overcontrol. I'm running essentially stock: the only mod I have is Better Burn Time, which ought to be completely quiescent unless I have a maneuver node set, or am close to entering or leaving atmosphere, to a rendezvous with a set target, or to impact with a body like the Mun. Even when active, it's not demanding; it does calculations I could have done in real time in BASIC on a 1986 Tandy Color Computer. I have one other flight in progress, a Kerbal day or so from a maneuver, but that vessel ought to be on rails when I'm not flying it, so shouldn't take machine time comparable to a vessel in focus. I'd welcome any suggestions how I could improve performance, short of buying a faster computer. I regularly see my cores stepping up to as high as 3.4 GHz, and given modern Ivy Bridge or Sandy Bridge architecture, this ought to handle more than twenty parts, and reasonably should do so without the long "almost freeze" effect.

It appears this was never a KSP problem; somehow, my computer's power management system had been switched to "Power Saving" for all four (two real, two virtual) cores. In Power Saving mode, the CPU cores are run at the lowest possible clock for the task(s) at hand, in order to reduce energy consumption. This may have occurred when I was trying to stretch battery life before buying higher capacity batteries. To be clear, I don't generally play KSP on battery, but there doesn't seem to be a way (in MATE) to set the system to automatically switch from Performance mode when on AC power, to Power Saving mode when on battery -- in fact, the only place I've seen where I can change this setting is in the CPU clock monitor(s) that I have mounted in the system bar. I'm off now to ask on an Ubuntu support site whether automatic mode switching is possible.

The other way to look at this, for these projects, is that they couldn't have gotten where they were going at all, with available launchers, if not for the multi-year, multi-gravity-assist path they took. Cassini was the size of a camper van, but there were no more Saturn launchers for it -- it had to go up on a Titan IV (as I recall), and there just wasn't enough delta-V available to go direct to Saturn. Without the gravity assists (from, IIRC, Venus, Earth, and Jupiter), there would have been a choice: make the actual vehicle much, much smaller (probably little if any bigger than the Huygens sub-probe), so the Titan could throw it (and the fuel it would need for Saturn capture) direct, or cancel the mission. If you can trade off mission time against delta-V, you can do stuff like Clementine did, using a bunch of very weak Moon assists to raise its orbit enough to get to the Moon even after the insertion stage failed (but no, you can't do this in KSP, unless you have Principia installed and a computer that can handle the load -- the SOI and patched conics model doesn't do perturbations and distant gravity effects).

Something better than a potato, one hopes... Seemingly, that's a hardish thing to do with this game. My "new" laptop goes as high as 3.4 GHz, and still gets bogged down with a 50 part launcher.

Anything light enough to launch as as rocket ought to float in water, especially with empty tanks.

Hmm. I wonder if anyone has done any work on 3D printing in octanol? That would allow precisely placing the focusing cavities ("bubbles"). I also wonder how big this would need to be to ignite a fusion core big enough to be "worth the effort" -- i.e. significantly more powerful than the initiating explosion?

Absolutely, though it would make more sense to store tanks of nitrous oxide, which is can be warmed and midly pressurized to be a liquid on Titan. Lower pressure = lighter tank, and liquid = denser fuel, both of which improve overall performance. Even better, N2O has a much higher fraction of usable oxygen (by mass) than air, even at the same density. You'll have some fun dealing with temperature swings, though -- Titan's surface temperature is low enough that impure methane falls as rain and stands in lakes and "seas" (albeit at higher than standard pressure). Combustion, however, would be at a similar temperature to what we're used to, so instead of a jet turbine's combustion section running at ~800 C in a -10 C environment (jet cruising altitude), you've got ~800 C combustion chamber in a -200 C environment.

I'll give you fair warning: soon, you'll be bringing back science on these missions, and the Mk. 1 Command Pod has a strong tendency to burn the experiments off the outside of the pod during reentry. Go a little high, and you practically guarantee you won't get down with an external goo canister or a Science Jr. -- the latter will burn up even behind a heat shield, which will then not be attached to the rest of the craft.

I won't lie to you -- flying an aircraft with standard KSP controls is a bear. I've got more than a hundred hours of radio control stick time, flying aerobatics, very low speed (like, edge of stall) at low altitude, inverted 8s on a plane without direct roll control -- I'm not an artist with a stick, but I'm pretty competent. I've also built R/C and free flight model airplanes, so I have a good grasp of surface function, COM/COL relationships, and how to trim for stability. It's all I can do to get a KSP plane that's as stable as I can build off the runway in one piece without SAS. Previous advice about disabling extra control functions is spot on -- with my most recent spaceplane attempt, I got it to fly (in SAS) with roll/pitch surfaces combined, but it flew much, MUCH better when I put ailerons on the wings instead of elevons in the tail, and set every surface to a single function. The vertical rudder is especially important for this -- as @Snark pointed out, it'll guarantee adverse yaw if you leave the roll function enabled on a common "upper-only". As well, combining pitch and roll seems to result in nose-up or nose-down response on a roll command, especially if you're using "deploy" to gain a constant amount of decalage to provide pitch stability (decalage is a bad thing if you're going for high speed, BTW -- it'll cause you to make a huge loop as the speed builds up). Best thing I can suggest is to download some designs that are mentioned as "easy flying" and "stable" and practice with them. There's no shame in starting with a trainer; I started flying R/C with a basic sailplane, moved up to a no-aileron power trainer, which I flew the heck out of before attempting 3-axis controls. BTW, if you're interested in flying aircraft in KSP, you might consider setting up to use a joystick, at least for pitch and roll. Proportional control (as opposed to what old R/C pilots call "bang-bang" controls) makes the whole process far easier to learn.

Actually, depending on cloud height, raindrops might be immediately lethal. If the rain was water with 1% Os suspended in each drop, the impact wouldn't do significant harm, but if 1% of the drops were solid osmium, they'd have a terminal velocity close to the speed of sound (a round drop couldn't fall supersonic, at least at low altitudes) -- the rain would be like getting hit with the fringe of a charge of birdshot at 25 yards or so. Unlikely to kill, as demonstrated by Dick Cheney a few years ago, but getting caught in a shower could result in an ER visit to get the osmium drops picked out of your scalp and shoulders, plus possible eye injuries (looking up at what's hitting you is a reflex) -- and if your luck is bad that day, you could die directly from a raindrop wound. Going outdoors during the rainy season would entail wearing light armor and at least a hard hat and safety glasses, if you have more sense than a teen boy. Interesting gunshot fact: most times, unless a bullet is in a location where slight movement could be fatal, they aren't removed; the surgery to pull a bullet out is likely to do more harm than leaving the bullet where it is. The body will encyst the lead and if it doesn't rub on a bone or similar the lead won't dissolve -- hence the bullet can remain, harmless, for decades. That would not be the case if you were using osmium shot -- its toxicity is much higher than that of lead. In fact, cost aside, use of osmium shot would be a Federal crime in the United States, where it's illegal to use poisoned bullets or ammunition.

Compared to a guy who drives a limo for a living? Evel did pretty well. He never had to punch a clock, he only really worked a couple days a year, and could still afford to replace the bikes he destroyed. If he'd made it over the Snake River in 1973, he'd have been richer than Elvis just from the TV appearance fees.

Fortunately, SF6 is also one of, if not the densest gas known. Since gas density (at a set pressure and temperature) is proportional to molecular weight, with a molecular weight of 32+(19x6) = 146, SF6 is more than three times as dense as CO2 (MW 44). On Venus, you'd get an atmosphere that shrinks significantly, as the denser gas will compress the bottom a lot more than CO2 can. Atmospheric pressure (in an atmosphere that's almost entirely CO2) will approximately triple, going from 90 bar to 270-ish bar. Can't tell you what it would do to the temperature -- the atmosphere would be less deep, but the gas would block more of the long-wave infrared. If I had to guess, I'd say it might get hotter, but couldn't guess by how much. On Earth, with only a fraction of 1% of the atmosphere affected, you might actually get a net cooling, because of the density increase relative to CO2. The gas would tend to sink to ground/sea level much more strongly than is the case now, and if it did so strongly enough to even partially differentiate (which CO2 can do in very sheltered locations when the concentration is high), the net greenhouse effect would be reduced, due to significant areas (highlands and mountains) rising above the bulk of the greenhouse gas. On Mars, the atmosphere would shrink as it did on Venus -- but without 270 bar resisting, the effect would be much more pronounced. The atmosphere would wind up concentrated in the Valles Marinaris, Hellas basin, and other deep depressions. Most of Mars would get colder, rather than warmer, as it would be exposed to vacuum instead of slightly protected as it is now. Edit: woops, I read that as all the CO2 becoming SF6. With only 10% changed, you'd get some atmosphere shrinkage on Venus and Mars, and some pressure increase, but not as much. Earth might not notice -- the net replacement would amount to less than .1% of the atmosphere, or less than the anthropogenic increase in CO2 over the past two centuries.

Aha! After my experience with this setup on early-career suborbital tourist flights, I never tried it at higher speeds/altitudes. If it won't slow down from 800 m/s, what would make me think it'll slow down from 2300+ m/s? A more horizontal reentry, however, could bleed off more speed high up and avoid a high vertical velocity component. No, I'm not using FAR, but again, my experience with the combo was at lowish speeds, finding it wasn't terrifically stable even as it failed to slow below 300 m/s high enough to avoid "splashed down hard" results.

Not enough to matter for thrust asymmetry. I once read that if one SRB ignited and the other failed, the entire stack would (if it could hold together) rotate through 90 degrees in less than a second. Challenger's destruction was completed when the leaking SRB tore completely loose from the tank, and the still-attached SRB turned the stack 90 degrees to the Mach 2 windstream -- which no portion of the Shuttle was built to withstand.

There was a novel by Stephen Baxter, Raft, which (incidental to the plot) explored some of the physics of gravity on a flat plate (the plate was the disassembled hull of a starship, after it had fallen through a wormhole into a universe where the gravitational constant was something like ten billion times what it is in ours -- stars were ten miles across, and when they died, a matter of some decades, left behind a ball of porous iron with 3 G at the surface). Bottom line, gravity points inward to the barycenter of the plate. The further you get toward the edge, the "steeper" the plate's surface gets, and at the very edge, you could stand (in greatly reduced gravity, since you're now much more than 4000 miles from the center, assuming mass and density are also preserved) with your body parallel to the "ground" of the upper and lower surfaces. The titular raft of Baxter's novel had an apparent slope of around 45 degrees near the edge, but a wider plate could still get significantly steeper.

He's been a daredevil for decades. He's like Evel Knievel without the big bank account. The Flat Earthers are just a means for him to have the money to build and fly his rocket. And if this one doesn't kill him, the next one will, and then he'll have gone out as a daredevil, instead of a sad old man in a nursing home. I can see it, a little. But the way my luck runs, I'd survive the crash and wind up paralyzed, and have to live on whatever disability gives me and with whatever medical care is available on a charity basis (because disability won't even pay for health insurance, never mind uninsured health care).

One major problem with the Mk. 1 + Crew Cabin -- in my experience, during reentry it will never slow down enough for the parachutes to indicated "safe" to deploy. You either have to change the default "when safe" setting and hope the canopies don't shred, or have some additional means (extra weight, extra funds) to slow down after the hot part of reentry is done. Turning the stack sideways isn't it, BTW -- that stack is stable-ish in heat shield forward, and really stable in command pod forward, but you won't have enough torque in just the command pod to keep it from going pod-forward if you turn it more than a few degrees from heat shield forward. Any science instruments on the outside are prone to burn off for any reentry hotter than LKO, too -- and if you add a Service Bay, you're adding cost and mass and making the stack less stable in heat shield forward -- i.e. more prone to tumble when tumbling could mean burning up. With the Mk. 1-2, external instruments are better protected, and you can mount a Service Bay on the nose if you won't need a docking clamp there.

I just watched your video -- I don't think that's what they mean by "land speed record" -- the way I understand it, you have to have the ground supporting the weight of the vehicle. Wheels, or at least skids. With the right mod, you might be able to use ground effect (like a hovercraft), though in real life I wouldn't expect that to work at supersonic speeds...

Two different factors make airplanes want to turn on the runway. Torque, certainly -- but the one that killed low-time pilots on their first Corsair flight was called P-Factor. When the airplane pulls angle of attack, there's a period when the airflow into the propeller isn't parallel to the shaft; that angled airflow means (for a nose up, like rotation for liftoff) that the descending blade has a higher angle of attack than the ascending one. This pushes the center of thrust off the shaft in the direction of the descending blade (still assuming a positive angle of attack) -- and with a right-hand rotating engine like virtually every single engine aircraft, induces a left turn. You can feel this turning force in a Piper Cub or Cessna 180 (most readily in the tail-dragger versions, as they'll usually rotate more sharply -- I've even experienced it with radio control, with a fractional horsepower engine), but when you scale up from 80-180 horsepower to 2000 horsepower, the turning moment is ferocious. Pilots of the bent-wing bird used to call it "the widow-maker" because, if you took a pilot from even another single engine taildragger like a P-51, and dropped him into a Corsair, his first takeoff was likely to result in a sharp left turn, with dihedral raising the right wing into a near-vertical bank at less than a wingspan of altitude. Even a Corsair couldn't fly out of that. BTW, the Corsair had this so much worse than anything else in WWII because it had the biggest engine ever (to that time) fitted with a constant speed propeller; at takeoff power the propeller pulled a lot of pitch trying to soak up the tremendous power of the two-row radial engine (which also produced a lot of torque reaction, but ailerons to counter torque roll are a lot larger than rudder countering P-factor turn). Other planes with similar horsepower -- like the P-51 -- had either fixed pitch, or manually adjustable propellers, and other airplanes with constant-speed props (most of the Navy fighters of the day, plus the P-47 and a couple other land-based types) had less horsepower -- and land based aircraft weren't routinely flown for STOL performance like carrier airplanes were. Your jet-prop monstrosity shouldn't be seeing P-factor; you're not nosing up. Shouldn't be seeing torque turn, either -- there's no torque on the frame of your contraption, just as there's no torque on the fuselage of a tip-jet helicopter. Most likely you're getting a vibration from the imbalance in the rotating parts causing flex in the frame that makes the wheels "steer" as it flexes and deflexes -- and the timing of the vertical component of the vibration causes the flex to mostly result in left turn (the matching right-turn flex occurs when there's less weight on the wheels, so has less effect on direction).

You'd have to land it back on the pad (ready to refuel and relaunch) to get 100%. Now a whole crew of Kerbals have to climb up on the roof, dismantle the rocket, and haul the parts down by crane. Or they have to haul fuel hoses up there and refuel the stage, so someone (I'm looking at you, Jeb) can hop it back down to ground level so a crawler can haul it in. And a rocket like that burns through a heckuvalot of fuel hovering for that kind of move...

I'm running a barely-modded KSP 1.3.0, without Steam, on Ubuntu Mate 16.04.3 LTS. The computer this runs on is a Thinkpad T430, Core i7 (dual core) 2.9 GHz (w/ turbo to 3.4 GHz), 8 GB RAM, Intel graphics, and a platter hard disk with more than 100 GB free space in the /home partition. I also run, simultaneously, MilkyWay@Home, though with its "nice" priority setting it should release clock cycles and appear never to be there except for the small amount of RAM it uses (less than 1 GB). My mod list: Better Burn Time. I've noticed yellow clock routinely, since installation, with vessels as small as 30 parts. That seems to be about normal for a machine in this clock speed range. Today, however, I noted that from time to time the yellow clock would completely stop incrementing for up to fifteen or so real time seconds at a time. At the same time, my vessel (a 25 part space plane, flying approximately level, over open ocean out of sight of land, on jet power at around 200 m/s) would completely freeze, ignoring control inputs, though the altimeter would continue to count up or down and sound (wind noise and the whistle of the Wheesley engines) played uninterrupted -- setting this apart from the stuttering sound that accompanies liftoff in a vessel with too many parts. I've noticed that my performance in this save (my first career, and the only save I play regularly at this time) has been going downhill over time, but this is ridiculous. What information is needed to determine and correct the problem?