damerell

You don't say. I feared so.

You can detect what the user is doing with the action groups and flight controls. I don't know if there is a way to accept input beyond that.

That said, they are a bit prone to horrible landscape discontinuities. :-/

To 125 degrees East, notwithstanding Jeb hurting his foot kicking a Snacks can around: Terrain on this leg seemed mostly to be ridges across the line of travel. It's still tricky to see what the far-off terrain is in the dark, of course, but I hope Kerbol-rise is coming soon.

Also rotate the orientation 90 degrees each time so everyone can see where they're going.

I seem not to be able to find album 2... am I missing something, please? I fear you have discovered something I also discovered; if a rover's on Minmus it it is going to roll and you've just got to design around it. Still, at least it's inside replacement-sending range.

No Electric Charge? If a rocket with an always-on antenna can't be communicated with on the pad at KSC, that's not a problem with anything up in the sky.

Not pressing the buttons around the screens?

FWIW, Mobile Frame System adds and removes nodes on demand on parts that expand and contract, and its parts are utterly festooned with nodes if you turn them all on. Seems to work.

Steady on, did I miss something, or are you ahead of DRE?

Part count is part count (more or less), yes. But 56 US wedges? That seems quite a lot.

There are some gotchas; a vector is a direction and a velocity but not a roll state, and a rotation doesn't have a magnitude but does have a roll state, and they're sort of interchangeable but sometimes you get undesired effects like this.

It seems to me that 1.0.3/4 heat is a bit buggy. Mods seem often to have curious consequences. But turning on thermal debug and seeing in the right-click menu where heat comes from would be useful?

I suggest you be more specific about what happens when you try; quote the precise error message, delete half and see what happens, etc.

Count me in. I may have disagreed slightly with ferram about the merits of CKAN, but I'll try to reproduce bugs as best as I can.

Unless I am very much mistaken (and the documentation is too), dishes only operate a cone when pointed at a celestial body. ETA: but if that's not for reasons of technical feasibility, I like your idea.

On reflection, I think it might be better if the contracts popped once the part is unlockable, if that is practical.

Have you tried ferram's Better Buoyancy mod? It makes the angle of an impact with the water matter, so a seaplane can touch down without disintegrating.

I use a Mk I command pod and a Mk I inline. Not so, ah, imaginative as that above, but it gets the job done and if you fluff the landing the inline's high crash tolerance gives you some chance of getting away with it.

You can install a specific version of a mod via the CLI. Has anyone? As far as I can tell, everyone would like it to be correct, much as there's been an argument about some other problems. "Metadata should be correct" seems to be an utterly uncontroversial statement. I think it would be doing modders an enormous disservice for CKAN to provide an easy way to install mods believed to be incompatible, completely at odds with the way that it can be an asset for modders as well as users if it consistently provides correct mod installs. Squad put out 1.0.5? You're no worse off than you were before CKAN existed; but now you have the option of testing mods and getting their metadata fixed. That's exactly what I'm going to do when I finish my current expedition in 1.0.2 - if Murdabenne hasn't done the lot.

There's a three-throttle quadrant on the yoke (one of which is already KSP's main throttle, for the nose engine); I've not been roving the last couple of days, but I'll not have any trouble coming up with a hands-only control scheme.

It might be better to report it in the FAR thread with exact steps to reproduce it, starting from a fresh KSP install.

That's a complete non-sequitur, in no way addressing the point that FAR does not have a complex set of dependencies. This: Replaces: heimdal-servers (<< 0.6.3-12) Provides: ftp, rsh-client, telnet-client Depends: krb5-config, libasn1-8-heimdal (>= 1.4.0+git20110226), libc6 (>= 2.11), libdb5.1, libedit2 (>= 2.11-20080614-1), libgssapi3-heimdal (>= 1.4.0+git20110226), libhcrypto4-heimdal (>= 1.4.0+git20110226), libhdb9-heimdal (>= 1.4.0+git20110226), libheimbase1-heimdal (>= 1.4.0+git20110226), libheimntlm0-heimdal (>= 1.4.0+git20110226), libhx509-5-heimdal (>= 1.4.0+git20110226), libkadm5clnt7-heimdal (>= 1.6~git20120311), libkadm5srv8-heimdal (>= 1.4.0+git20110226), libkafs0heimdal (>= 1.4.0+git20110226), libkrb5-26-heimdal (>= 1.6~git20120311), libotp0-heimdal (>= 1.4.0+git20110226), libroken18-heimdal (>= 1.4.0+git20110226), libsl0-heimdal (>= 1.6~git20120311), libtinfo5, libwind0-heimdal (>= 1.4.0+git20110226) Suggests: heimdal-docs, heimdal-kcm Conflicts: ftp (<< 0.16-1), heimdal-servers (<< 0.4e-7), kerberos4kth-clients, kerberos4kth-user, netstd, openafs-client (<< 1.2.2-3), otp, rsh-client (<< 0.16.1-1), ssltelnet, telnet (<< 0.17-1), telnet-ssl (<< 0.14.9-2) isn't even a very complex set of dependencies. (It's also been observed elsewhere that this isn't, perhaps, the vast comedy of metadata errors one might have supposed existed.)

Stubbed it on the bedpost, so as mundane as it gets, but equally a broken toe is basically just a matter of sucking it up and waiting...

Coo. I hope neither of them is eating beans too often.