Tiron

I've got one of these on an escape trajectory at the moment... Edit: Wrong link: http://kerbalspaceprogram.com/0-18-4-hermes-deep-space-probe/

A program that opens up more resources by closing stuff for you isn't going to help KSP, because its limitation is that it can't USE all the resources in the first place. RAM aside, it can't use more than one CPU Thread, and thus, more than one core. Now a program that say, forced it to multithread, by emulating a single CPU to the game while actually multithreading it behind the scenes...that would help a LOT. It'd be absurdly hard to do(absurdly, ridiculously hard), but it'd help. Be easier to just port a non-crappy physics engine as a Unity plugin.

Don't forget to make sure that the kerbals in question have their state set to 1 (in flight). If it's still 0, they'll show up on new flights...and on Laythe too. It forgets to change that sometimes... States: 0=available 1=in flight 2=??? 3=Dead

This is on the list of Mechjeb's many, many features. The landing module can calculate approximately where you'll come down based on your current course...or estimate your orbit after aerobraking if you're not coming down on the first pass. It's pretty accurate. It also has an 'autoland' mode (it has autopilots for just about everything), but you can use just the prediction too.

Eyup. Your problem is mechjeb2's autostaging: Even with all functions off, if autostaging is enabled (via checkbox), it will automatically stage through any stage that doesn't have a decoupler on it. I've got the latest dev build but I've been playing with Rovers so I haven't seen the fix in action, but the autostaging was allegedly fixed, and an autostage checkbox has been added to what used to be called 'Throttle Control' and is now called 'Utilities' (along with an 'autostage once' button, no idea what that does).

EVA Kerbals can repair broken wheels...and it might not be the low gravity. I've had problems with my (much lighter) rover with the TR-2Ls being unstable too. It appears to be some suspension problem with the TR-2Ls...there's a note in the 0.20.1 patch notes about adjusting the suspension to fix a jitter issue that sounds suspiciously similar, so I'm wondering if that fix got pulled from 0.20.2 somehow. Since I've clean-installed twice AND tested it with no mods the second time just to make sure. As for what I did today...I tried to make an SNES style Arwing (not the version from the newer games you see around already) from memory, and it was horribly inaccurate and performed even more horribly, so I trashed it. Right now I'm trying to decide what the heck I want to do, and given that my rover doesn't work for crap on even remotely hilly terrain due to the TR-2L problem, I think the answer is 'Play Something Else'.

Hmm, there shouldn't be an unplug option unless it thinks it's already plugged into something (I've seen it happen, mostly when it HAD been plugged into something, but usually only after saving the craft and reloading it...but it only caused problems with the ports for me, fixed by 'unplugging'.) Have you tried right clicking on the winch instead of the connector? It gets a little funny about which you have to click sometimes... Also, I've noticed a bit of an issue myself: It's impossible to make a connection between either of the radial connector ports and a connector while in the hangar, in either direction. It works with the stackable port but not the radial ports. Not sure why, probably a cfg issue...I'll look into it in a sec.

The sound workaround consists of moving ...\Kerbal Space Program\GameData\Kethane\Plugins\PluginData\MMI_Kethane\sounds to ...\Kerbal Space Program\PluginData\MMI_Kethane\sounds Minus that non-existant space in MMI_Kethane (It's not there in the post when I edit it, it's something the forum software is doing)

While I agree that doing it manually a few times before doing it with mechjeb is a good idea, that's kinda mean... and what the heck is a 'Glorious Manpatrick?'

Biggest thing to watch is that if you're not on the right pane in maneuver planning, it will sometimes drop your target as you click through to get to the proper transfer option. In which case you just retarget. He's talking about using Mechjeb. 2.0.x uses a modified maneuver node system to do just about everything, including the Trans-Munar Injection burn. For the record, Brofessional's method is the 'manual' method, which actually works quite well: If you're in an approximately 0 degree inclination orbit around 100km or so, you want to burn straight forward just a bit after Munrise occurs directly in front of you, until you show a mun encounter. That's how I did my first few mun landings in the old 0.13.3 demo... which didn't show encounters on its map yet, but Science! marches on.

Given that we've only got partial IVAs, it could still happen?

ETA: May 24th, 2013.

It has to do with the way the fuel flow logic works: Certain types of setup confuse it utterly and result in things not working. Not to mention the 'fuel crossfeed capable' parts are erratic about when they'll crossfeed and when they won't, in my experience anyway. They're right about the Converter just being an engine that runs in reverse: It's set to produce no thrust and to burn negative fuel. In game-engine terms, this means it's *pulling* negative amounts of fuel from the tanks the fuel flow logic can reach. This results in fuel being ADDED to those tanks, because you're subtracting a negative (yay math). It also means that the game treats it as if fuel were flowing TO the converter FROM the tank instead of vice versa, so yes, the fuel lines need to point AT the converter. You can actually test it by replacing the converter with a normal engine, and doing a static burn test(Use launch clamps, and don't release them). Any tanks that engine pulls fuel from, the fuel from a converter in that position will reach. One thing a lot of people miss, though: Xenon and Monopropellant are 'universally routed' (there's no flow logic, it can go everywhere automatically)... and so is Kethane. Your Kethane tanks don't need to be anywhere *near* your converters. As long as the Kethane tanks are on the same craft as the converters, the converters will be able to get the Kethane.

Yeah. Some people have actually complained about being able to illuminate a planet from orbit, and there are mods on the spaceport with less floodtacular lighting to fix it. There's a few other options though: 1.) In IVA View, there's a Radar Altimeter on your control panel that shows distance above ground rather than barometric altitude. 2.)Mechjeb's 'surface info' pane has a 'height above ground' item. 3.) Turn your gamma up a bit?

It labels itself as 1.0.0.0, but I *distinctly* remember the link he put to it being labeled as 1.0.0.2, thus why I called it that. You'll also note that the spaceport name is 'docking strut 2', which suggests he uploaded it second. I suppose it's possible he re-listed the 1.0.0.0 version as 1.0.0.2 just so people would think it was the 'newest' version and use that(Since it worked.)

I'm a bit...unclear on what exactly this entails. I tried copying the KSP\GameData\Kethane\Plugins\PluginData\MMI_Kethane\sounds to KSP\PluginData\MMI_Kethane\sounds as this seems to indicate and got no sound. Edit: Aaaaand redoing it just to make sure, and it works this time. Must've typo'd or something...w/e.

Yep. Getting a patch alright... strangely I wasn't having memory problems from my mods...maybe I wasn't using enough with pngs?

That's an 'unimplemented planned feature'. I suggest you search for 'Ferram Aerospace Research' on the spaceport if it bugs you that much

Not having to try to get logged in to the squad store every time there's an update. I'm already logged in to steam, so BAM! Given that squad's password recovery systems really don't like to actually send me anything(I'm looking at YOU, spaceport), this is kind of important.

The launch clamps don't have a height value to edit: They go down to the ground from wherever they're placed. They thing to remember is that wherever your ship is placed in the VAB is where it will be placed when it gets to the launchpad. If it's offcenter in the VAB, it's offcenter on the pad. Height is a pseudo-exception: If it's floating in the air, it'll be moved to sit on the ground. Unless you're using launch clamps. In which case it will stay at whatever height it was at in the hangar, the launch clamps extending to the ground, no matter how far that, is to keep it there. What you need to do is not to edit to clamps, but to remove the scroll and placement limits in the VAB so you can place it through the top of the roof. I suppose you could try to hack your position in the persistence file, but isn't there some tool called hyperedit for that?

I've seen that happen in 0.18 and 0.19 with regular CoTs, and found an easy solution: Add some struts across the joint. They seem to stop the shifting and break the instant you decouple it.

I use http://kerbalspaceprogram.com/docking-strut-2/ for this, since it's a lot more realistic than quantum struts (Has to be a base for the strut to connect to, for example, and looks like a regular strut). Not sure if it still works since my entire KSP is on hold awaiting fixes to KAS. (and maybe Kethane? Is kethane broken too?)

Is that's what's causing that stupid camera bug? Huh. And he's aware of the 'stuff doesn't work' problem and working on it.

I need to farm dil on STO anyway...and I still got a looooot of mapping to do. I'm just sad I have to fly the spaceplane with the motorcycle on it back to duna...again... D:

I do too...if only it still worked