steve_v

Dunno about stock, but in FAR a wing with a negative AoA will quite happily produce "downwards lift", as evidenced by the ability to fly upside-down. The CoP is not the CoL as it would be in stock. Note that there is no arrow attached to the blue ball, indicating that the force the horizontal stabiliser (or any part for that matter) is adding is not necessarily "up" or "lift". Ignore that confusing little blue ball and look to the analysis graphs, they tell a truer tale. Ed. OTOH, ignore my attempt to simplify and just listen to ferram, who actually knows what he's on about.

Well it is tagged "serious proposal" & "not a joke" is it not?

Look in the "attitude adjustment" MJ window, and play with the values there - A first try might be "use stock SAS".

My guess: excessive SAS PID controller gain. IME the stock SAS system does this if you have a lot of control authority on a light vessel. IIRC, StockBugfixModules only tunes the pilot RSAS system (e.g. hold prograde etc.) If it is excessive PID gain, you may need to mess with the standard "stability assist" too - Unfortunately Regex's PID tuner no longer exists, but PilotAssistant has tunables for the stock SAS - try dropping the gain (P) a bit on all 3 axes.

Ahh, the standard (not shielded) docking port still has a decoupler attached - it'll be blocking docking. Switch to that craft, right click the docking port and hit "decouple node" to detach it (then try to get it out of the way), use a stack separator instead (decouples on both sides) or loose the decoupler altogether - you don't need it, since you can just undock then redock to the same port. ED. actually, no - shielded docking port won't work. Just stick the probe directly on the docking port and use the "decouple node" trick to detach it, then spin around and dock.

Though I haven't actually tried it, I suspect turning email notifications on and enabling push (or whatever equiv in ios/Winphone) in your mobile email client would achieve this. It'd be a handy feature, but IMO wouldn't justify another battery/data sucking background app if it can be done with existing software. I'm somewhat allergic to the "my phone must annoy me with trivia every 5 seconds" thing that people seem so keen on anyway, but each to their own.

Find the appropriate .craft file in your saves directory and upload it somewhere, e.g. dropbox. Then post the link here. This is a pretty odd issue, you got any mods (other than KER) installed? What does the right-click menu for the engine say? - it should tell you why it flamed out.

Correct. Where are you uploading them to?

IIRC you'll need to be a certain distance away from the port you want to dock to before the 'magnetic' docking mechanism will re-engage, I cant remember exactly what it is but 10m or so should do it. Also set "control from here" on docking port of the craft you're controlling, and "set as target" on the port you're docking to. I still can't see that screenshot - the forum doesn't host images, so you'll need to upload it somewhere publicly visible and link to it or use the URL with the "insert other media" button. Try imgur or postimg.org

Yeah, this. Part count first, efficiency second and aesthetics a distant third. Also all docking performed on the day side because lights add too many parts. Since 1.0 hit it's been Kerbal part-count-reduction program.

Not I, that's what a web browser is for. I really don't understand this current craze for 'app' versions of every website - most of them are little more than a lightly customised shell around the stock browser and only serve to consume memory and disk space. What would such an 'app' offer that a well written, mobile friendly, OS agnostic website could not? A kerbal calculator, perhaps - but again, what's wrong with ksp.olex.biz? To make a convincing case for an app, it needs to do something only a locally installed app can do. It also adds at least 3 different platform dependent code-bases to maintain, I'm not seeing the need TBH.

Way I see it, it has to be 'all or nothing' - either they go totally open source and release all the specs, trade secrets included... or they're going to have to do the bulk of the work themselves. Nvidia has, apparently, chosen the latter - and this is the thing that irritates open-source developers. It's annoying, but at least the thing works. The real question is: is AMD willing to release all the details of how their cards work, now and as new features are added? - 'cause that's what's needed if the open source community is to develop or maintain a usable driver. If they don't, I suspect we'll be hearing "F* you AMD" from a certain kernel developer soon.

True enough, but, as you say - at least it works properly. Ugly, working code is infinitely better than any kind of not-working code. Nvidias driver used to be pretty bad too, but at least they always have a release that actually works. AMDs track record on the other hand... summarily dropping support for older cards, with no 'legacy' driver available, failing to update their code for months and putting people in the position of 'downgrade the entire X.org stack or have no OpenGL' etc. This lack of commitment to keeping up with the times, combined with the complete lack of drivers (not counting FOSS drivers, as not AMDs work) for other Unixes (e.g. FreeBSD) makes AMD graphics products a solid no-buy for me.

True, but even "barely" e.g. running audio decoding in a separate thread, technically counts as "multithreading" . It's just not multithreaded where it would help performance in any meaningful way.

Yeah, AMDs Linux driver is a turd, it has been for as long as I can remember.

KSP is multithreaded... but the physics engine isn't, and that's where the bulk of the computation is. AFAIK x64 is the same.

BuildID.txt in your KSP dir.

While this is indeed true, the danger is not static discharge to the HSF assembly, it's accidentally contacting and discharging into other components. If you're using a vacuum cleaner on PCs in a professional setting, I sure hope you've got an antistatic tip on the thing - while relatively rare in the first place, static damage to components can manifest itself long after the machine has left the shop. To be safe, one should use either an antistatic brush + some canned air (being sure to hold fans to prevent bearing damage) or a vacuum with an antistatic tip, one with a brush built in being most effective. Damage due to static discharge is actually quite rare, assuming you're not removing individual components, but do be sure to ground whatever you're using (including your hands) to the PC case / ground plane before touching anything else.

Perhaps you are happy with 20FPS, I am not. Frames-per-second == number of graphical updates in one second. Whether this is due to slow graphics processing or the game waiting for something (physics calculations) to complete before pushing the next frame to the render queue is irrelevant - the result is the same. I would much prefer the game runs physics slower than realtime to maintain a decent framerate, however there is only so much that can be achieved by adjusting physics delta. And no, I'm not at all prepared to put up with the game running like a slideshow to get those physics calculations done (green timer). As well as graphics updates becoming unpleasantly slow, it causes a bunch of other issues, such as input lag. Mucking with the physics-delta slider is simply trading one symptom of shoddy physics engine performance for another.

Uh huh. A mighty reliable source of information and full of valuable life lessons I'm sure. And the signal-to-noise ratio degrades further...

No, I did see that, but it doesn't make it any more relevant. If you're aware that it has nothing to do with the issue at hand why bother suggesting it in the first place? First, identify the problem (in this case, clearly a CPU bottleneck). Then suggest solutions based on that... i.e. not mucking about with RAM or GPU. Or providing incorrect information and editing it later, for that matter. Indeed, and that particular mod did do a disappearing act not long ago. It's back now, but you can't count on it working in 1.1. It's fairly invasive too, and will probably break craft if it goes away... then again I wouldn't count on craft surviving the transition to 1.1 anyway, I know Squad promised to try not breaking saves, but it's a big change.

Interesting, I've never seen nor heard of anything like this in KSP... any mods installed? The game slowing down gells with the CPU overheating and clock throttling, but that would be a message from the OS, not the game.

Considering that KSP is only utilising one core, and modern cpus can do individual core clocking (AKA turbo only works on one core), cooling shouldn't be a huge issue... the bigger problem is likely going to be the lack of support for overclocking of any kind in most laptops.

Of course. Good luck getting funding though, it's hard enough to get the general population to care about a certainty 10 years away, let alone preparing for something that probably won't happen in their lifetimes. It'll take imminent, obvious catastrophe to get any sizeable commitment, and even then there will be plenty who simply refuse to believe.

Egads man, just like the LAA flag (and no, "force games into using more ram" is not what it does), or the "2GB limit" (you said it, not me) that's got nothing to do with it. Since the GPU is twiddling it's thumbs at ~30% waiting for something to do, buggering about with hidden GPU driver settings will do absolutely squat. It's pretty obvious it's the usual single-core performance bottleneck at work here: Physics delta, CPU OC, part-welding or wait. Yes, and no. Thermal management strategies aside, a CPU is a CPU... but you have to look closely at the specs, as laptops often have slightly different versions of the same chip, usually with lower clock limits or more aggressive power management.