radonek

I'll second that.

Imagine you are descending to mun, gently reducing speed to soft touchdown… and then a meter above surface you give a bit too much thrust and instead of 2.5m/s fall you get 0.01m/s rise. Can you see it coming?

Well, this is a real problem since dawn of time. IIRC one of apollo missions had trouble with latches not engaging and had to resort to some eee… very obscene maneuvers to lock with LEM.

You could probably bring it down in one piece, but I doubt you can land it safely without chutes. LN-Ns have poor performance in atmosphere and that beast of your is big and heavy. (Also, I consider running LV-N down over habitable parts to be a bad taste.) You could bring up heatshield and chutes, attach it via docking port and (with some careful piloting) land it, but that would be more expensive then just ditching the whole thing… I'd say forget about it. If you want to save funds, best way IMO is designing small and efficient single-purpose crafts.

I went through some Kerbin-Mun transfer tutorial, which after successful left me with empty transfer stage and some simple lander in munar orbit. So I googled some simple landing instructions and went for it. After disassembling lander I realized I forgot to quicksave so I went through that transfer tutorial again. Its not like more practice could hurt, right?

I just made my first shoot at NERVAl pusher. After 4minutes burn it was this -><- close to explosive meltdown. And you know what? I LOVE IT. It adds a nice bit of challenge to design. Yet even a bad ship can be flown with some care and patience. LV-N was in dire need of nerfing and adding thermal management is way better then just lowering stats… Way to go Squad.

http://en.wikipedia.org/wiki/Space_Pen Everything could have been invented "otherwise" (and frequently is). Especially from post-factum perspective.

This is a great idea. And all it need is a way to display flight data outside of game. I'm pretty sure I've seen mods for that…

I think you'll find easier to turn that engine block of your into full-blown tug then juggle around with orphaned engines.

In theory, yes. In practice… your vehicle sports 2.5t, dressed up kerbal is 90kg… What do you mean by EVA-like? Disabling reaction wheel will do no good. Docking mode merely switch to different (and in my book, useless) keyboard layout.

I can think of few improvements: One big battery bank is plenty while extra SAS is always handy. Tanks are farther apart, helps to move CoM around by pumping monoprop between them. Same goes about RCS blocks - farther they are from CoM, more torque you can squeeze off them. Small photovolt panels should be enough most of the time and are not sticking out as much. Also not prone to "forget to deploy" fail. Monoprop engines are below docking ring level, less likely to get struck by accident. (Would be event better at waist level, but this looks cool to me :-) ) As for maintaining balance: if your cargo is passive, you turn off RCS blocks on opposite end, so that remaining RCS is as close to CoM as possible. If cargo have its own RCS, you turn off whichever ports comes handy. Also note that while you cant see CoM in flight, camera is centered on it.

There may be a little fallout due to impurites in fuel (not much, stuff in fuel tends to make rockets go kaboom) and part erosion (even less, for obvious reasons :-) ). However, nukes are very easy with shielding to save weight. Anything close while they are operating will become irradiated quite a lot due to neutron flux. NERVA itself was never meant to be used as first stage since launch facility would be geting hot with repeated starts.

My 2 cents: * good tug can serve you a long time, so its worth it to put some thought to it. Also its easy to replace making it a good testing field for funny ideas. * Easiest way to "solve" balance is to just have a lot of SAS force. A big gyro ring is a must, more are better. If CoM is off in a big way, you can disable rcs ports, but tug should be able to eat up some difference. * Have a enough batteries to power all that SAS power. Having solar panels sticking out while maneuvring around things is not fun. * Do not forget to add lights so you can work on dark side too. * It's handy to have decent fuel and monoprop tankage on board so you can top-off fuel in smaller ships or move few buckets of fuel somewhere. * My tugs are based around a single LV-N. Not only are they able to push cargo around orbits and to moon/minmus, but heavy engine and fuel tanks act as counterbalance. It can be made to quite a compact design. * Sooner or later you will bump into something, so it should be reasonably rugged.

impyre just got it mixed up a bit, his maneuver is useful to turn orbit from prograde to retrograde or vice versa.

Oh my, if my gentoo box hear of this, I'm dead. What have I done...

I'd never thought I would see anybody looking to linux to play games… First, you need to pick your favourite flavour, or "distribution" and a desktop environment. Simply put, you download a distribution image, throw it onto dvd/flashdisk, boot it and look if you like it. Booting up from removable medium takes a while longer, but you can try things without hassling with installation to disk. You can also test if your hardware is properly supported. Some to choose from (but there are much more if you are picky): http://www.linuxmint.com/ (kde, gnome2 and "conservative" gnome3 desktop) https://getfedora.org/workstation/ (gnome3 desktop) http://www.ubuntu.com/download/desktop (unity desktop) KDE is very sophisticated and configurable, good if you like to tinker with things. gnome and unity are more like "one (well thought out) size for all" If you know any linux user who can help you, just ask and get same distro. Once you have your favourite, look for tutorial for that specific flavour. Most distributions have some "getting started" documentation right at eye level.

I don't think this is good approach in this situation. All the time you spend down in well waiting for best launch window, asteroid will be falling down gathering speed and will be that much more difficult to both intercept and move. I'd say its better to shoot off asap, even at cost of wasting a lot of dv. Hohmann is efficient, but slow – you spend a lot of time up near AP. I'd say: plot a fast track close to target orbit. Could be even escape trajectory if fuel permits. Only when close to target do a transfer burn. If both orbits are close enough, it will amount to full reverse. Yes, it will take a lot of dv, but you'll need WAY less fuel to move that rock.

Designing overengineered ships and landers. And, believe it or not, docking.

I would not vote for either. As said above, short and squat designs are way to go. If you slap fuel tanks on crew module sides, not only you have much lower CoM, but you can also have CoM much closer to DCoM. As a bonus, you attach to them landing legs (and anything else not worth getting back up) for little more dV saved when you ditch them. And pushing heat shield all the way to the Mun, down and back is just a waste.

All those "silly fantasy" ships sound more like job for Space Engineers to me. Only ship that I would like to have in KSP is USS Discovery from 2001 Space Odyssey. And send it on Jool mission of course :-)

Darnok, there is a story you might be interested in: Just before world war two, some british government official decided that no venue should go unexplored and started science project to develop a Death Ray. For real. So you had bunch of real scientists, with a budget, and objective of devising ANY way to make EM radiation inconvenient to humans. Or, more specificaly, nazis. And, as should be of special importance to you, with no cellphone manufacturere or whoever influencing them. So, boffins made some calculations and experiments and decided that no, it can't be done. Not even if fate of british empire was at stake. Just so you know we are talking smart people here, those same scientists decided it would be a shame to let that money go to waste (read: to nonscience) so they used it for what would be today called "a major misappropriation of funds". Back then, they called it "invention of radar".

Eggs and baskets sir, eggs and baskets.

True. But that is why I stated that kernel itself is fine - if you run all static binaries. It's all those 32-to-64bit wrappers that are, in my book, emulation. Call it compatibility layer if you like... my point is its these layers that makes things complicated. Reason is what I'm missing here. Again, on my linux box, everything is 64bit and works just fine. On windows with all those fancy compatibility/emulation stuff, many 64bits apps are broken. Some of them, like Unity, have same codebase. Which is exactly my point. When you get rid of these, 64bit windows will be as good as linux. And you get there by running as much code as possible without emulation.(edited) As a sidenote, linux compatibility is nothing like WoW64. It's much simpler - dynamic linker can tell 32bit ELF from 64bit one (obviously :-) and is configured to use different LDPATH. There is set of packages (x86-emul-linux-*) installed there that provides wrapper shims of most common libraries. You can run multiple instances of same library via manipulating LD_* variables, but this is feature of the linker and is not used much. From what I understand, WoW64 works more like Wine, setting up separate enviroment for every binary (my .wine/ look a lot like \winsxs). I'm not claiming that 64bit is any kind of magical key. Actually, I quite agree with most of what Renegade said about 32bit code being better off. I'm only saying that legacy emulation is a bad cruft, and you should run native - be it 32bit apps on 32bit system or the other way. As for my "observations", my only observation is that my linux box can run anything 64bit including KSP just fine and windows can't. Something that people around here still fail to absorb.

Umm, I see here so many misconceptions about 64bit arch I don't even know where to begin. But let me try… First, 64bit cpu can't run 32bit applications just like that. Seriously. It can chew 16bit/32bit instructions. Unless you run 8086 real mode code, running instructions is like 5% of "compatibility". Most crucial 5%, but still just a tiny bit of all the work needed. Lot of the other work is done by kernel, which have to contain compatibility layer with complete legacy syscall interface. This is complicated in itself, but fine if kernel is only thing your app comunicates with. But that only apply (and only to a limited extent) to statically linked binaries (read: DOS programs). Whenever your program comunicates with other, things get wee more complicated. To simplify a bit – legacy app can talk to other legacy app and native app is friends with other natives, but they don't mix together well. You could in theory have complete stacks for both, but in practice there are lots of thing you can't do twice. For instance, you can't have two GPU or keyboard drivers, so you end up with 64bit binary and wrapper that maps 32bit calls onto it. You can't really do it other way around - that could lose some of those extra bits. So here is another thing – whenever you get native code in stack, everything under it must be native too. 64bit texture library need 64bit openGL library which need 64 bit GPU driver which need 64bit kernel… you get the idea. Note that I'm talking binary interface here – how one .dll comunicates with other. This is why running 32bit windows on 64bit cpu is easy – BIOS sets up a few things and everything else is 32bit only. This is also why you can't run 64bit apps on 32bit windows, even if cpu would be happy to see them and kernel could in theory be patched to allow them. Now, this is still easy peasy until you start thinking dynamic. Libraries. Dynamic linking is complicated stuff even at best of times, and windows is as far from best of times as "dll hell" can get you. Even a simple program nowadays links tens of libraries, and for big apps this can easily go to hundreds. These do not form simple up-down graph from app to kernel as above, but are interwined together to what can easily become unholy mess (see any office app). Now, if some of them start talking different its very easy to run into problems even with all kinds of wrappers and compatibility layers. This is why many big apps (like firefox or openoffice) took so long to get native. Not because firefox can't make use more memory, but because untangle all its libraries is not an easy task (further complicated by bad practice of bundling libraries which can wreak all kinds havoc when interfering with their system versions. But that's another story). In case of Firefox, it took several years even on linux, where transition is simple: all 32bit to all 64bit. On windows, many third parties can't be bothered to provide 64bit versions, and we are stuck with system that is not actauly able to work without some really deep and scary magic, involving keeping multiple copies of same library. And it ends with silly situation where we go 64bit to have more memory in which to hold all those conflicting libraries that should not be there in a first place. It's no wonder that \winsxs on my box is as big as complete winxp install – it is one. With some redundancy on top. To complicate things a bit more, amd64 arch is not merely about adding another 32bits to some registers. (See PAE for that, and note it can be made to work on 32bit system). It is way more complicated (linux kernel amd64 arch was for a long time completely separate from x86 arch, same way as arm or sparc or whatever) which, apart from kernel level headaches, also mean that 32-to-64 bit wrappers are not nearly as simple as adding 32 zero bits to registers. Same problems can be exhibited by any other means of communication: COM, IPC, network protocols… anything that want to make use of 64bit stuff will have to deal with changing APIs or even ABIs. Full transition may be tricky, half-assed approach just hides garbage under carpet. Just seeing how many system daemons under windows is still 32bit makes me shudder. All of this is even more pronounced with KSP since its graphic intensive application (read: game) which means lot of low-level stuff. What if that improperly typed integer is pointer to buffer that gets passsed via GL to graphics driver that does DMA transfer off it? We are talking ring0 code here, and all kinds of bad ....… What would be at worst simple segfault for other app is like minefield for the likes of Unity. If all of this sounds like hell, it is not. It works great on linux. Comes with with mentality I guess – porting is common task in *nix world and any coder sticking with emulation without very good reason would be laughed off as either lazy or clueless (sorry Daid). Because whole system is native and compatibility layers are only used by very, very few apps, there is little room for trouble. Hell, I don't even have all emulation packages installed. And that is moral of the story: There are no "32bit" and "64bit" apps. There are native apps and apps sitting on top of huge hairball of emulated legacy cruft. Redmond guys did incredibly great job of hiding that cruft and even making it work most of the time. But its still cruft and to actually get rid of it, there is no other way then go full blown. You can have perfectly good 32bit system, or even better 64bit one, but there is nothing good in between.

And you, sir, are prime example of why 64bit windows are slow moving form "major pain in the ass" to "slight nuissance", never mind being actually useful. Even if your app has zero advantage in running 64bit (and actually slight penalty that comes with it), your users will have significant advantage of running native. Don't you find it strange that linux port of Unity, while getting much less attention then windows one, is just fine? Is linux Unity somehow magic? Let's see… On my linux box, 100% of installed packages is 64bit. And all of them work just fine. On win7 box, about half of system is 32bit, and anything 64bit exhibits all colours of trouble (still great compared to 64bit XP though). Doesn't look to me like it's just "some more virtual memory space". 32bit emulation need some complicated and error prone machinery, and geting rid of it is advatage for your users even if app itself does not change one bit.