LameLefty

Ah, thank you. I know I had things working properly in the past (0.23.5 I think) but it's been awhile. On OS X you cannot merge folders the same way you do in Windows so when something requires installing into sub-folders of sub-folders, you have to put everything in place manually. Guess I missed a step here.

x86 - the x64 version is for the 64-bit versions of KSP.

I finally got around to adding this mod back into my 0.90 game but the Deadweasel texture packs aren't working properly in the VAB for me. The right-click context menu item shows but the texture never changes. I've got the alternate textures their default DeadSkins folder inside the AviationLights folder. in Any ideas what I might be doing wrong here, or is this an incompatibility with 0.90?

For what it's worth, 0.90 under OS X seems to become unstable due to RAM usage for me right around that point too. Since 0.19, I've been able to get up to nearly 3.5GB until problems; however, I've had several crashes-to-desktop under 0.90 at about that same 2.5GB point, more or less. It does take me several hours to reach that point however. This is new behavior for 0.90.

Drop backwards compatibility and do it right. But either way, I will continue to play with FAR/NEAR. As long as Ferram keeps updating them, it won't affect me much.

Using The Cars as a soundtrack was genius. You get some rep just for that touch ...

In order of frequency: 1. Staging sequence errors 2. Wrong Kerbal sitting in the command pod 3. (Much less common) Insufficient first stage control authority (MOAR FINZ!)

Keyboard and trackpad on OS X. Works just fine for me.

I communicate for a living these days. You sure seemed defensive. PROTIP: Get that chip off your shoulder before you reply to an internet post. I introduced real-world NTR's merely to point out heat-flux, not just choice of propellant, matters most of all. For that matter, given the low density of LH2 and the attendant volume (and mass) of tankage required, a higher molectular-weight propellant such as ammonia might be an even better real-world propellant.

Been to and landed on all of the above. Moho is the toughest due to the high dV required; that plane-change is a real PITA, and even if you optimize your transfer planning and execute the burns perfectly, you need a lot of dV to make a landing and then make orbit and break the SOI again. The transfer back to Kerbin isn't too bad but the difficulty is so front-loaded that after you've managed those first tough parts, the return is anti-climactic. I like Dres well enough - it's got a very interesting canyon feature and there are transfer windows that aren't too far apart. But Eeloo is just kind of bland - not even any interesting features or easter eggs. It's not very hard to get to aside from the time involved. If you run a parallel missions type game, that one crew won't have anything to do while you run potentially dozens of other, more interesting missions to other destinations in the meantime.

Um, try not being so defensive and, you know, actually reading what I wrote. I didn't write "temperature," I wrote "energy flux." I was precise, and I was so for a reason. And with regard to the differences between NERVA and Timberwind, they're irrelevant to the discussion at hand - both were NTR rocket designs and neither one of them ever came close to a flight-qualified design. Having actually designed mission- and crew-critical spaceflight hardware (which hardware now has many years' flight experience behind it), I know the differences between prototype and production hardware very well.

I'm not but if I was ... Create a new Sandbox save and test - you'll figure it out pretty quickly.

This. Mod. Is. AWESOME! I spent a couple hours worth of real-time in the first week after 0.90 dropped trying to complete a series of survey contracts on Minmus. This would've made that process so much simpler. So here, have some rep!

Ferram does it again. THANK YOU!

Gotta correct/add to this - you're right that the high ISP is/was due to the fact that the working fluid (e.g. the propellant) was hydrogen. But you have to remember the other big factor in real-world ISP: exhaust velocity. NERVA had insanely high exhaust velocity, and it it obtained that high exhaust velocity due to a really, really high energy flux to heat and expand the working fluid to those high velocities. Without something like VASIMIR (which hasn't even reached scales of the Timberwind NERVA tests), the only way to get those high exhaust velocities at the same mass flow rates to give good thrust is to use a nuclear thermal core. So .... anyway, just read Kommitz's plan for the next update and I can't wait. I heart these engines so much.

Oribits can easily be plotted by hand with paper, pencil and a little geometry. Admittedly, a slide rule or calculator makes it a lot faster. The toughest things about Apollo mission planning were, in order: #1) TT&C (tracking, telemetry and control) - they used a worldwide network of ground stations, airplanes and ships to keep a lock on a carrier signal for Doppler measurements; those were used for very precise measurement of velocity and distance. And #2) iterative estimates for burns. As we all know from KSP, changing your orbit doesn't happen instantaneously - it changes with every impulsive event, and - again from KSP - we know that mass changes as we thrust due to propellant consumption. So this is a non-linear problem that has not simple formulaic solution. You have to use an iterative calculation to simulate how the orbit will change over the length of the burn. This is trivial now due to advances in computing power - it was NOT trivial in the 1960's. It required long, tedious calculations step by step on paper, or using a room-sized mainframe to do it in several minutes to several hours - the more precisely you want to simulate, the longer the calculations take. But anyway, yeah - being able to simulate stuff like this in KSP more or less instantly is amazing to this guy - I learned to do it the hard way in college on paper and then used 16 bit PC's to iterate orbit maneuvers and thought it was magic when I got an answer after a couple minutes.

Why complicate with a gravity assist? Just use the Map view to set your apoapsis at the same altitude as the Mün, then burn at apo to circularize.

I've been playing this game since 0.19 and today, thanks to 0.90 and the integration of Fine Print contracts, I did something very basic that I have never, ever even tried: I put a station into solar orbit complete with a crew of five foolhardy - er, "brave" - crewmen! Cost almost 85K in Funds but returned me over 150K and over 250 Science, plus the Science I obtained from EVA and crew reports in solar orbit.

Yep. This. I rescued two Kerbals in my current save this way, without the usual expedient of launching two Mk.1 pods to do it.

Let me just be clear: I *AM* an aerospace engineer by education and (formerly) by profession. I understand it just fine. But a simple scroll through the FAR thread from beginning to end shows that many, many people don't.

Um, it's Blizzy's mod. It seems to me he's pretty much earned the right to say whatever he wants about. You don't have to respond if you don't like what he has to say.

I can't see Squad doing something as complex as FAR, with its myriad data display and build/estimate tools. But a simpler system that uses the same concepts but easier for the end-user would be great. Something like Ferram's more idiot-proof NEAR? Yeah, that's the ticket.

Without lat/long grids on the default stock Map view (something I've really, really wanted for many versions now), I've never tried one of those target-orbit missions yet. Are the target argument of periapsis and longitude of ascending node displayed on the Map view when you take one of those contracts?

I did all this stuff in college in the 80's for my aerospace engineering degree. Pencil, engineering grid paper and a calculator ... I don't bother with any of that anymore. I can eye-ball most designs well enough to work. They may not be optimized every time, but I play each new Career game by iterating some basic designs as necessary. Good enough for me.

And that's why you haven't already seen this answer a few times ... That's because an SAS module only provides torque for control, it won't provide the control you need for stability. A Stayputnik probe core alone won't do it either - you need a higher-tier probe core.