Twurtz

There's a pill for your problem - it's called more thrust and stamina (deltaV). Fnar.

Open debug menu (alt+f12) Click 'show input lock stack' (can't load up the game right now, but I think that's what it's labeled), then 'clear input lock stack'.

Open debug menu (alt+f12). Clear input lock stack.

Pretty sure it's part of the 'SXT' (Lack's Stock Extension) parts pack; the cockpit is named Ke111.

I'm willing to bet 20 Funds on it being DistantObjectEnhancement, if you have that installed. Version 1.6.3 (current) fixes a lot of these 'spare flares'.

Looking through the configs in the 1.3.0 .zip, it looks like SoyJuiceG.cfg is missing a 'scale = 1' (under asset parameters, right before 'rescaleFactor = 1'). I'd imagine the engine crapping out when told to rescale something it doesn't know the base scale of. Can't test from this PC, but I'd consider it a likely candidate for the source of the problem. Edit: Tested, that wasn't it. Still getting [LOG 17:46:57.446] Look rotation viewing vector is zero spam before camera cuts out after about 25 seconds.

Myeah, it doesn't help that this is the 'wrong' Mk2; The profile used by B9 is not the same as the stock one (though the stock one came later?), and the different cross section means those parts don't play well with stock. You'd need at least the fuselage parts from B9 to use this cockpit properly. The colour scheme I find is easily fixed with Gimp, but that is another matter.

BahamutoD's excellent Mk2 Lightning Cockpit is an option there. SXT has a SU-27 Mk2 to Mk1 'neckpiece' Quite liking these, been looking for new cockpits to crash in. I like building fighter aircraft (for strictly peaceful scientific purposes only!), and found the selection of MK2 cockpits with good visibility lacking.

I have noticed that with the KAC window open, and a few alarms running, memory usage spins out of control really fast. Idling at the KSC scene with the window open with 10 alarms eats into my precious, precious memory reserve at about 1MB every 3 seconds. With 5 alarms it's around 1MB per 4 seconds. 2 alarms 1MB per 7 seconds, no alarms 1MB per 9 sec. If I close the KAC window I get a blissful 12 seconds between 1MB baby steps towards a Krakeny doom (praise the Kraken!). The type of alarm seems to make no difference, and removing KAC entirely yields the same result as having the window closed. In other words, if I keep the KAC window open, my game will crash (faster). If I have a few alarms it'll happen even faster, and with a bunch of alarms it's basically one launch or flight (unless they're very short), then restart the game. Anyone else seeing this?

It just now happened to me with a launch in career mode (which would be a tier 3 launchpad); removing all clamps from the core stack, and adding to the side boosters instead, made the clamps stay on the ground where they belong.

I have seen this 'phenomenon' before, both in recent and older versions of KSP and in modded and stock installs alike. Personally I refer to it as my ship having 'the clamps'. It doesn't seem to happen with all craft, and it doesn't always result in collisions, sometimes the launch clamps just seem to become lonely and want to say 'hi'. It seems to happen more with the FASA clamps than with the stock ones. A workaround I usually employ is sticking a couple of radial detachers on the vessel, then attach the clamps either to those or to something you place in between, such as a strut block, to provide a bit of clearance. You then launch as normal (in whatever fashion you like to release your clamps) and then drop the radial detachers afterwards. I have never observed any post-launch clamp-biting when applying this somewhat clumsy approach, and it always fixes the problem for the craft that has 'the clamps'.

I recently had the same problem. In my case it was apparently incompatibility in the way TAC and ModularFuelTanks edits parts, resulting in the same behaviour as you mention. Since RealFuels is, as far as I understand, pretty much based on the same approach, but with slightly different outcomes, my guess is you'll find removing RealFuels will solve the problem.

I'm using the ejection fix .dll, and haven't personally experienced the violent ejections on EVA, but it does look like they exit the pod in a unintended fashion, face first heading out, then suddenly spinning around to face the hatch. I suspect that the problem is worse if the physics engine is slowing down the game to the point where it becomes extremely laggy, and it's on the spinning around people get flung off, I've only tested under low strain conditions with next to no time dilation. When I look at the pod in the VAB part selection menu, it appears as if something is sticking out of the airlock - at first I thought it was an animation placeholder of sorts, but reading about this issue, it would appear to me as if you do have something on your model in the hatch area, that could collide with a kerbal and send him/her/it on a vomitous spin. Don't have a screenie to back up my ludicrous claim, but you can see the magical black kerbo-repulsive transparent box thing if you mouse over the pod in any of the editors. Without having a proper clue, my off-the-bat guess is your collider thingy for the hatch is backwards or sticking out, but when it comes to things I know very little about, I'm often wrong . As for the pod in general, I like it very much - at first I thought it was a bit too, hm, 'clean' looking compared to the stock models, but using Ven's Stock Revamp it fits in very well, and fills the gap between MK1 and MK1-2 pods nicely.