Blackstar

It's likely. ATI had a long track record of terrible OpenGL support in their drivers. It's gotten a little better under AMD, but not much. I always recommend nvidia cards to people who make heavy use of OpenGL as they've always had pretty good support for it.

Both the mission time counter and TAC life support units use Earth time. Kerbin's rotational period is 6 hours, but "1 day" of life support means 24 hours.

That's what the reactors in the Interstellar mod do. Attach an electric turbine to one end, and a thermal rocket nozzle to the other, and the heat generated by the reactor can be used by either. Throttling up lessens the rate of electric power generation, though the Megajoule -> Electric Charge conversion rate is so high that you effectively have unlimited power to any stock instruments even at full throttle.

If it's a manned mission, transmitting anything but crew/eva reports is almost always a bad idea, unless you are stranded and unable to make it back to Kerbin. Now that you can move science around on EVA in 0.23, just take it out of your experiments and store it all in the capsule before you jettison them, so you can get 100% value for everything.

Either add more parachutes so the experiments survive, or EVA and move the science into the capsule. Surface samples and Science Jr. reports from Mun or Minmus are a big chunk of science each. Land in different places to get more, but remember that you can only use a Science Jr. or Goo Canister once per mission. Resetting it erases it, so you don't get the science points. Take multiple if you're planning to make more than one stop.

You already edited your post, but yeah. The big difference on a 64-bit OS is that all the kernel code runs in 64-bit mode anyway, so it doesn't need to be 32-bit addressable. The user application can get the whole lower 4GB range to itself (minus a small stub for interfacing). Executables that aren't marked as large address aware just aren't allowed to touch the upper 2GB no matter the OS. I'd have to check but I think LAA is the default on newer versions of MSVC. I don't think /3GB is even a valid startup flag on 64-bit Windows, or if it is, it doesn't do anything.

Well, you can just turn it on by editing the PE header. It's usually safe to do so, unless the application uses tricks like stealing the high bit of a pointer to store a flag, but those are very rare, especially outside of low-level system programming. You don't need to for KSP, though. I just checked its binary and it is already marked large address aware. That's consistent with my observations (typically see 2-3GB memory usage on my setup). It should work -- since KSP is large address aware it can use the extra 1GB of user address space if you're running the OS with /3GB. I'd only do that if you're stuck on 32-bit and are desperate though -- in nearly all cases you'd be better off just upgrading to a 64-bit OS. In the past there have been occasional driver incompatibilities with /3GB, most often video drivers.

Abandon ship and and try to circularize on EVA? I don't remember how much deltaV an EVA pack has, but with an apoapsis of 1000km, you might just have enough. If you can get him into a stable orbit, then you can take as much time as you need to get a rescue ship to rendezvous.

I would be sad to see "Target active vessel" go away, as it's quite handy if you know what you're doing with it. Is hiding it behind an advanced mode setting instead of removing it completely an option? The only legitimate problems I've encountered with RT2 so far (that haven't been fixed): 1. Vessels that are unloaded from the active scene do not correctly act as relays. This is easiest to see with an example. Mothership M has a big dish and an omni antenna. The dish is pointed at the home satellite network. Probe P, which has only an omni antenna, decouples. It's fine, so long as it stays in physics range of mothership M. As soon as it gets past 2.5k and the mothership unloads, P loses its connection and can no longer be controlled, even though it's still well within the range of M's omni antenna. Quicksave and reload is the easiest way to fix that problem, but it's still annoying, especially if the probe is in the middle of a circularization burn, or worse, already in an atmosphere. 2. Sometimes RCS stops working after undocking. I haven't yet done scientific testing to prove that this is a RemoteTech bug, but it seems to only bite me when I have RT2 installed so I'm about 75% sure. The symptom is that you simply can't turn RCS on, even though you otherwise have control of the craft. Again, quicksave and load fixes it.

I'd be perfectly fine with automatic targeting of vessels if (1) Power to any inactive vessel that particular transmitter was supplying cut out, shutting down background processing for refineries, science labs, and even life support if there's no local power available. It may already do this, I honestly haven't tried it since I'd consider it cheating to take advantage of if it doesn't. (2) Power to the new target only kicked in after appropriate signal delay as required by distance / speed of light. Though given how much people hated it from a gameplay standpoint with Remote Tech, I really doubt (2) would ever be implemented.

OTOH, as someone who's actually worked with real life seismic data before, I can say that 6500 packets is downright tiny for it.

Microwave power seems more OP to me than the Vista. Beaming gigawatts through space with a beam tightly focused enough not to dissipate over interplanetary distances, pinpoint accuracy, and automagic targeting of the active vessel? Needs some downsides, like instantly cooking any Kerbal who goes on EVA while the ship is receiving that much power.

Just happened to notice a new parody video:

I tend to go with a combination of a mission registry and a name. Registry numbers are usually three letter acronyms based on the class of the vessel (i.e. which file in the VAB/SPH it's launched from) followed by a mission number that increments for each vessel of that class to be launched. OTV=Orbital Transport Vehicle, IEP = Interplanetary Exploration Probe, etc. After starting a new save, I traditionally name my first 3 real (non-experimental) workhorse tugs OTV-101 Grissom, OTV-102 Chaffee, and OTV-103 White. Those three ships have different specialties and do most of the orbital assembly of whatever big mission I'm planning. If I do a Mun mission, the ship to land there will often be named Collins, just because. After that, it's whatever random thing I feel like at the moment. Oh, and I tend to create a big space station called Kerbin One even though I rarely use it for anything. The design varies wildly from one game version to the next depending on which mods I'm playing with, but it typically has plenty of habitation space, docking ports, and sometimes fuel reserves.

The career mode surface samples from Minmus indicate that it is unfortunately NOT a delicious dessert. At least the surface. But maybe dust from meteor impacts has settled at the top layer... we should dig deeper and see if there is delicious dessert just under the surface!

Two theories tend to float around: 1. Minmus is a recently captured (recent in cosmic terms) body from much further out, possibly a comet. Being closer to the sun is slowly causing it to melt/sublimate. In a few more hundred thousand years of exposure, it might disappear entirely into a cloud of gas. 2. The anomalous ice has something to do with the extremely high density seen in all stellar bodies in the Kerbin system. Or it could not be ice at all -- I'm not 100% sure where that comes from. It's always looked like greenish sand and crystal to me.

Fine control mode puts RCS thrusters in 'balance' mode, which works best if you have two sets of thruster blocks far from the center of mass. It attempts to throttle back the individual ones to compensate for less than perfect placement. The idea is that even with unbalanced RCS blocks, fine control mode can translate without introducing (much) rotation. If you have a single set near the COM (but not quite perfectly aligned), it usually ends up reducing your thrust to near 0, since it's trying to solve an equation that there is no solution for: you're going to get some torque no matter how far back you scale the thrust. So it's not very useful in that case since you'll get almost no force at all out of them. Note that while in fine control mode you often won't be able to see the puffs, even if you do get translation (and said translation will usually be a lot slower than running them full blast). Fine control mode also seems to disable or at least significantly reduce the automatic use of RCS for orientation control when SAS is turned on, depending more on reaction wheel torque. I do often notice a very small (0.1 or less) resource drain with SAS on, so I'm not certain if it's completely shutting it off, but it definitely is a lot less wasteful.

Or, as I found out the hard way recently, if you have FAR, Deadly Reentry, and Real Parachutes installed, deploying chutes during or before reentry is a really bad idea. Which makes perfect sense; IRL they'd catch on fire or be ripped to shreds too. I had just gotten used to KSP's default chute model totally ignoring the canopy and only simulating physics on the housing. Yeah, MJ's calculations all assume stock aerodynamics, so most of the autopilots will do the complete wrong thing in an atmosphere. Definitely avoid the ascent and landing autopilots, which I never used anyway because I prefer to control things by hand for those. I still keep it installed just for Smart A.S.S. because it's handy to tell my ship to point along a specific vector without having to make constant corrections around the orbit (and more realistic, too, in the case of automated probes!). Surface mode is useful in the atmosphere as well to hold a constant heading. Plus I prefer some of the flight readouts to Kerbal Engineer's.

FWIW I read that as "[the lander's] aerodynamics are crap" -- and installing FAR made it a lot more obvious than the stock model. The language is ambiguous enough that I could see it meaning either though.

^^^ This. The initial pitch bump shouldn't be more than a degree or two. If your rocket is balanced, then you can take your hands off the keyboard and it will just about fly itself. The only thing you might have to tweak is the throttle, depending on how heavy the rocket is. One question for technion is does your rocket have tail fins? They are pretty much a must to do a proper gravity turn in FAR. The fins catch the air and help keep you on your prograde vector. Even static ones without control surfaces will do. It's possible to do it without fins with lots of manual control, but much more difficult.

The reason is that in stock KSP, the lower atmosphere is very thick and "soupy". The atmospheric density there limits your terminal velocity to the point where doing the gravity turn early is inefficient and wastes a lot of delta V fighting the air resistance (or more accurately, having to fight gravity more than you should because your airspeed is limited and you can't get enough upward momentum while also flying at an angle). You simply can't go faster than a couple hundred m/s in the lower atmosphere, so there's no point in trying to build up lateral velocity so soon. Once you get above 10K, the air gets really thin really fast, so by turning there you can start building up to orbital velocity. Having FAR installed changes the atmosphere of Kerbin to more closely resemble Earth's atmosphere but at a smaller scale. With that mod, the atmosphere is thinner earlier, but with less of a sudden falloff as you get higher. Starting your gravity turn right off the pad does make a lot of sense in that case and that's how many people launch rockets with FAR. Note that FAR's change to the atmosphere makes achieving orbit require less effective deltaV for rockets, essentially making the game easier. If that's not what you want, there is an ISP adjuster mod you can install to compensate, or you can do what some of us do and add more challenge mods (Deadly Reentry, RemoteTech, etc) to add the difficulty in other places instead. EDIT: Or of course, you can stick with stock, armed with the knowledge of Kerbin's unique atmosphere and what the most efficient ascent path is for it. Whatever is fun to play. Table of terminal velocity on Kerbin at various altitudes is here: http://wiki.kerbalspaceprogram.com/wiki/Kerbin#Atmosphere

I'm not sure I'd like to see KJR stock quite yet. Maybe eventually, but right now there are too many issues to be ready for prime time. As it is, I've installed KJR 3 or 4 times and always ended up uninstalling it after a while. Sure, it makes (most) stack connections more rigid, but it seems to make a lot of other joints much MORE flexible than they should be, especially trusses, I-beams, structural panels, and (ironically) struts. Constructions that are are rock solid for me in stock, even if I have to add some struts here and there, bend like spaghetti with KJR and no amount of struts seem to fix it.

Target and "control from here" doesn't matter for docking. It certainly makes it more convenient, but ports will always dock if they're close enough. EDIT: After closer review of the video, I *think* they're the right way around. I still don't see the window (low texture settings maybe), but the outer ring looks correct. If the tanks are full, the magnetic force probably won't be able to move them any. You need to either be perfectly aligned, or come in even slower.

Was looking for this as well since I'm still running 0.22 until all the mods I use are stabilized; and until I have time to deal with any changes they've made. The 0.23 version hangs on the loading screen. Google cache had it: https://dl.dropboxusercontent.com/u/70818657/ProceduralDynamics0.5.zip Should be okay (I hope) as the author still has the old version in their dropbox, but I'll remove the link if it's not kosher.

You could decelarate with your LV-Ns, then use RCS to flip it and land on its belly. RCS should be plenty for the final touchdown, it doesn't sound too heavy from the specs you posted. Though that might not work if you have some fragile solar panels on the side.