radonek

RCS ports placement is art in itself. This is why you really should do your first docking with small, maneuvrable ship. Yours is quite heavy and ports does not seem to be well placed. For more complicated designs, RCS Build Aid mod is a must.

You are just being nitpicky. I know of only one movie in similar "real" setting – Armageddon. Whose staff evidently believed their audience is bunch of cretins who would eat **** if covered in shiny color. Yes, Gravity have some obvious fails, but you can tell its authors did lots of research, put a lot of effort to have things right and resorted to "artistic licence" when they could not move story otherwise. Actually, while looking things up I found some of percieved "fails" were in fact correct. Somebody really did his homework on this one.

Zero Kerbals killed in line of duty.

Less complicated (and a bit less fuel efficient) way I learned from wiki: Make sure you are int target mode. Turn to pink circle. Burn a bit. See target closing. Turn retrograde (yellow cross) and wait until target is closest possible. Burn until your relative velocity is zero. Rinse, repeat. Every cycle should bring you a bit closer to your target, once you have it in hand you will se how and why Flight's method works.

Without mods, no. If you do not want to go with mechjeb, look for PreciseNode mod.

From what I gathered on Linux thread, not always but its widespread problem. Both of my linux machines suffer from it.

Well, everything really. AFAIK Windows can set resolution and set one display as primary. That's it. Windows 98 could do as much, and only improvement I could find in win7 are some "dualhead" wallpapers. For example, I have KSP set up in windowed mode of same size as display, and window manager is configured to make it borderless, positioned at center of second display. This gives me "fullscreen" game without locking mouse inside. Real story here is dedicated process that manages desktop and, among other things, can enforce positioning and size (and much more) on any window. While this is useful in general, I'm sure you can see how this is incredibly handy on dualhead. Windows programs handle their windows themselves and it shows - some can remeber their position, some can even correctly handle maximized state, most of them not. Some can't tell maximized from fullscreen and have problems with focus stealing. Some work great, other can't stand such gross transgression as panel on top of screen instead of bottom. It's a mess. To compare with my example, KSP on Windows is ilustration on how to make dualhead most painful experience possible. It starts in center of "desktop" to get all advantages of being cut in half, but is not smart enough to actually span over all that space. If it just picked one screen at random, it would have at least 50% chance to get it right. Even if wrong, it would be clearly visible and not broken in halves. But no, its better to make you move it by hand every ****ing time, right?

Overengineered landers. And docking. That never gets old.

Apart from running Better System ? :-) Honestly, no. There is bad bug in Unity for linux with mouse being oversensitive. It's "only" annoying in-flight, but damning in VAB and SPH. Only thing I can think of where you'd be better off with linux is multihead. I'm using two displays for years now and Windows still feel like stone age.

Same thing. You have memory which you can't use without going through some hops and can't pass along to anything else. MSDN says, among other limitations: "AWE address ranges cannot be used to buffer data for graphics or video calls." What use can game engine make of it? If you need to squeeze some big database tablespace into memory, you can live with that, databases tend to handle their memory themselves anyway. Otherwise, it seems somewhat less clunky API then using memory mapping, but it says you need to lock those pages into physmem, since its not backed by pagefile. This means running under escalated privileges, which is showstopper in my book. Nothing of this is relevant to KSP anyway – even if that memory could actually be usefull, you cant really go to Unity developers asking them to implement more difficult and less usefull then plain amd64 arch support.

I looked up that syscall at MSDN ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537.aspx ) and it seems to me to be just variation on posixish mmap(). You get swap-backed file handle and access it via ordinary file IO calls. You cant pass that memory to syscall, you cant allocate from it in library, you cant pass it to GPU as texture buffer. In short, you can't do anything except boasting you somehow "allocated" >4G of memory. Unless you reimplement most of core libraries in a very inefficient way, that is. Thus, "you can't use more than 4GB of memory in a 32-bit process" still holds, for any usefull values of "use". BTW you can do the same on *nix, and on linux you can do even better using hugetlbfs, but for exactly same reasons it is only used for very special workloads (mostly big databases). True enough…

What I gathered from article: to avoid 64bit arch rewrite, you "only" need to rewrite all memory code to use completely different mechanism. Which is incompatibile with any existing libraries or even syscalls. Outside of coding excercise, how does that help?

I stand corrected. Alas, I dare to say that "backward compatibility" is not the case anymore. I totaly believe it could wreak all kind of havoc on bad XP drivers, it certainly did on linux (PAE brings more then just a few bits to address registers, and for example DMA transfer by unaware driver can really ruin a day). But should not Vista+ drivers be certified, for exactly these reasons? Plus, amd64 arch still uses PAE (plus some extensions) so once you have working 64bit driver (which should be the case for Vista and later), you are halfway there. So, after two major iterations and XP being officially retired (and burried under a crossroad) I don't buy this anymore. It seems more likely to me this is just to pump people for server versions.

You can use more then 4G with PAE, courtesy of all modern CPUs. KSP would still be limited to 4G address space though.

Makes sense. Maintaining another arch may be costly. But… unity does have both x86 and amd64 versions on linux. And potential audience for win64 is probably larger then for both linux versions combined. And "lots" of win64 apps are just plain laughable, trust me. Right now, on my work linux desktop number of 32bit processes is: zero. Flash could be one, and if I really wanted to ramp things up, I could fire up skype to get one more. Thats it. Windows came a long way since 64bit XP (they actaully work) but still don't come even close. On my gaming rig, only "significant" win64 app is JRE. I don't claim to be windows expert, but makes more sense for me then idea of Unity making perfectly good 64bit linux port and then just dropping the ball.

64bits are useful not only performance-wise. Since it is completely new ABI, it is also a chance to get away with lots of legacy cruft on kernel level. It certainly was a big improvement on linux. As for windows, I don't think it will work anytime soon. Problem is not with 64bit bits, I'm using 64bit linux for years and it works like a charm. Hell, even 64 bit KSP works, and that is an alien there. If there is ever a problem, it's with legacy 32bit apps. But we were using 32bit apps for decades and no problem there either. Problems arise when you combine the two - emulation layer is complicated and tricky bussines. Now, I recently got myself a new machine (mostly to have more raw cpu power for KSP :-) which gave my gaming rig a chance to move from XP to 64bit win7. Or so they say. I was kinda shocked to learn it is still for the most part 32bit system, almost all thirdparty code and even some system services are still 32bit. My bet would be that Unity itself does not have big problem with 64bits (it certainly does not on linux), but cant cope with system libraries of both kinds, intertwined into a hairy mess. And that is a problem of windows ecosystem as a whole and unity can do nothing about it.

I've just made this little fella...

Ummm, hate to spoil the fun, but that rover looks very top-heavy. Did you brought it for a ride around KSC?

Technical sidenote: it's not a "reactor". There is no chain reaction going on, just natural decay. You could refuel it, but why? After some hundred years, whatever it is powering is gonna be well beyond service life.

I had same problem after installing lazor docking cam mod.

Idea: how fast can asteroid rotate before breaking up? I guess its out of question for iron ones, but ice?

Yes, the idea that you can move a mountain of iron and stone wheezing around at tens of kilometers per second with a nuke really is crazy. I am seriously surprised you got to any velocity change at all… I remember when Armageddon movie got out (… of mental hospital :-) ) just about all scientists pointed out that idea of moving, much less destroying an asteroid with nukes is ineffective, implausible and stupid. Seriously proposed methods involved (relatively) small forces like solar sails, laser ablation, gravity a-tractors etc. working over extended period of time. AFAIK the main thing is that atomics are effective in terms of packing lot of energy – thousands of them is still small price for such a task. Its hauling them all the way from bottom of The Well that is wastefull. If you could produce them localy (ie, asteroid you are moving is rich in fissible material) that spell a different story…

Well, docking can be tricky but has one major advantage: you can practice at LKO until you feel sure about it. My advice is to start small – design smallest possible ship (mk1 pod, panel, chute, small retro engine, decent amount of monoprop. and, of course, docking port) and have some fun with that. Once you get used to things, you can try with real (read: heavy and unwieldy) ships.

If you are serious about avoiding mods, your biggest problem would be delta-v calculation. You can do a dress rehearsal on Mun: Lift you lander up, then let it do KOI-Mun-landing-Kerbin trip on its own. That's about 1600m/s delta-v, You need 1400 to get off Duna and have a bit on the side for soft landing. Once you are sure your lander can hadle it's job, you are set. You can take wrong turn elsewhere, but that can be helped with automatic tankers. It's not exactly bad idea to send one upfront, just to be one the safe side. If this is your first interplanetary transfer, a bit of practice can't hurt. (I speak from experience…)

It definitely can. And I dare to say that perfecting such design is way easier then fussing around with direct ascent. You just moar-strut it like any other part as necessary to withstand launch forces. Once on orbit, clamp-o-tron should be strong enough for anything you push him with. You can make it fail by kicking it with some high-TWR beast (yes mainsail, I'm looking at you) but using such ineffective engine at this point is error in itself. Plus, docking equipment can be invaluable if something goes south and you need to pull off a rescue mission.