steve_v

Nobody "doesn't like" 64bit KSP, but your case aside, the evidence that it is broken is overwhelming. This is not an opinion, it's a fact. This wasn't a big deal untill people started doing what you are doing now and making a fuss about it, hence the lockout. Please stop digging that hole, you are not helping. If you really must run 64bit, good for you, just quit moaning about it. Perhaps then this thread can go back to discussing FAR, as intended.

Congratulations, you have constructed your first kraken drive! On a more serious note: known issues with KJR, if you're running it, or part clipping - especially landing legs.

FWIW, such hints are more likely to be in the form of an oops from the GPU driver, either kernel-side or the Xorg glx client. With NVIDIA you tend to get something like: "NVRM: Xid <error-code>" but I'm not sure what output the AMD driver produces. From what I've gathered, the AMD Linux driver is a right mess at the moment, though some have reported improvements with the latest release. You appear to be running the 13.x series, which is pretty old now, so it might be worth trying the latest offering from AMD.

Nail meets head A live distro with generic drivers is fairly easy, a live distro that autodetects and installs a proprietary GPU driver, not so much. There are distros out there that do it, but i'm pretty sure I've not seen one that works with all concievable hardware. MS, on the other hand, works around this by simply not providing a live distro... Personally, I prefer my install/live disk to load the bare minimum of hardware specific drivers - just enough to get a console up. Less complexity, less potential for a no-boot scenario. This has the added benefit that if something doesn't go as planned later on, you have a fallback bootable disk to fix it with. While a live disk is a nifty idea, multiboot really is less hassle in the long run. I have a similar setup, GNU/Linux 98% of the time, with a Windows install I can boot for occasional Windows only games - a list that is growng shorter by the day

Yup I have some theories on why this is so, but suffice to say the most intelligent people I know all appreciate metal. Any dating advice I could give, on the other hand, would be unpleasant uncharitable and bitter.

FAR isn't hard, it's intuitive. Stock aero is just confusing. At first, I too made the noob mistake of designing rockets that actually look like rockets. I had to un-learn everything I thought I knew about aerodynamics, because stock areodynamics simply isn't. There were 2 things that came very close to putting me off KSP for good, one was the "bends like a bananna" springy joint effect & the other was the "flat rockets with no nosecones are more efficient" mantra of stock aerodynamics. Ferram has nicely solved both of these issues and I for one will be very disappointed if the upcoming aero overhaul doesn't take inspiration from his work. Honestly, I think I would have given up on KSP as simply being too silly and counter-intuitive if it hadn't been for FAR. FAR is easy, because if it looks like it will fly it probably will. Stock is ridiculous, because designs that certainly shouldn't fly do, and designs that make sense don't. The only "hard" part of FAR is that you actually have to think about the aerodynamics of your designs at all, to me that's a good thing. The very first response I got, the last time I introduced someone to KSP was: "I thought it was more realistic than this, what's up with aerodynamics?" - I rest my case.

I don't have an AMD card, but going by various similar issues reported it's I'd say it's probably GPU driver related. Some have had better luck after upgrading the AMD driver, what version are you running?

It's a bash alias, AKA a lazy tool alias for "get latest FAR from github, name it like "Ferram-Aerospace-Research-2015-01-13.zip"" 'cause I keep forgetting the url

Works if you DL the archive: Turn off AA/PPFX.

alias update-far='wget https://github.com/ferram4/Ferram-Aerospace-Research/archive/master.zip -O Ferram-Aerospace-Research-`date -I`.zip' ... bloody auto url tags.

Ahh, then it's even less of a "fix" than I thought

Yeah, thought you might say that. Symmetry in KSP is pretty ugly all round, I'll live with it. On a different note, I'm still getting stalling of control surfaces @ 15° AOA when behind a procedural wing, any progress on that one? I'm fine with designing around it, but it is somewhat annoying.

One small issue I noticed: If you're building say, a shuttle, and save the craft reoriented to the vertical for import to the VAB & ET attachment, the wing textures switch to radial symmetry (i.e. flipped) on reloading it: No big deal, but if you implement heat shielding based on surface texture things could get a mite interesting... EDIT: No, scratch that, not only the textures but the whole sodding wing assembly moved. This almost proved disasterous, destablilising re-entry and lifting the outer landing gear off the ground... still managed to land it though I'll have to re-investigate this, to make sure it wasn't "damaged during assembly" in the VAB, so to speak. EDIT2: Somebody find me that engineer! The wing displacement was just a SNAFU on my part but the texture swapping is still happening, as soon as the vehicle is rotated in the VAB.

Ahh, my favourite small spaceplane engine, inconveniently long at times but excellent performance

In theory it shouldn't be all that hard, there are plenty of USB bootable distros around, but "thumb drive" performance is typically pretty bogus, so you'd want to put KSP on a real HDD/SSD.

Top fans can be highly effective, (and fans are cheap) but if your internal components aren't overheating it's probably overkill. If you don't mind full speed, fan power can be aquired anywhere there's 12V i.e. molex plugs or... strip connector Lower speed can be obtained by connecting across the +12V and +5V lines at a molex / FDD / sata power connector, giving 7V to the fan. For automatic speed regulation, I'm a big fan of these.

Yeah, that. The issue here, as I understand it, is that MechJeb precalculates landing coordinates based on a known aerodynamic model. This is fairly easy to do in stock, since drag depends only on mass, velocity and atmospheric density - all of which are known in advance. With FAR/NEAR however, the drag experienced by an object moving in atmosphere depends also on it's shape and orientation (or ballistic coefficient) - things MechJeb does not and, to a certain extent, can not know in advance. Hence the innaccuracy. True FAR/NEAR support would entail integrating something like the Trajectories mod into the landing AP, as well as making assumptions about the re-entry orientation of the craft and/or or making in-atmosphere adjustments, accounting for lift etc... it'll get real complicated, real quick. You'd essentailly have to teach MechJeb to fly an aircraft in FAR. IIRC, stock drag fix makes drag proportional to volume rather than mass (still very wrong ) so I suspect this would be more reasonable to implement, assuming the required values can be extracted from the game. That said, it's been so long since I played without FAR that I can't really comment on landing AP performance, except that it doesn't work too well with FAR. IIRC it worked fine with stock last time I used it. I don't do C# either, so you'll have to ask Sarbian how hard this actually is

Keen as mustard Water takeoff / landing is sorely neglected in KSP & now that we have BetterBuoyancy... The time has come

Looking at that case, you've got top mounted fans, no? If it's only hot above the 5.24" bays thats not so unusual, there's probably no airflow through that part of the case. Although there's generally nothing that needs cooling up there, I'd check you haven't got anything exhausting into that part of the case & that your airflow is set properly - i.e. in at the lower front / centre side and out at the upper rear. Obvious as it sounds, I've seen people get it wrong before , so no offence intended if I'm preaching to the choir. I do notice some heat transmitted to the outside of my case, but it's mostly via the GPU bracket & certainly doesn't make it to the top. The GPU is always hot, 'cause this machine runs GPUGRID whenever it's not running KSP

Fair enough, though comparisons of actual readings (throwing a Q6600 into the mix for a third data point, all I have access to right now) do indeed show a 12~16 C differential between the case (thermal diode) and core (DTS) temps. Working out which reading is which can be interesting though, I only figured out which mislabelled (BIOS) reading was the case temp by comparing to an actual thermocouple... OFC, that's just *my* observations, YMMV, and my (or your) BIOS calibration may well be off. Better safe & all that. The 'crit' temp is that at which the CPU will halt, not good at all. But I've seen no casualties, even accidentally powering up a chip with *no* HSF. I've also seen a P4 motherboard melt through the antistatic foam it was sitting on... but that's another story.

Err, "Launch Date Q2'09", I was refering to the Q8400. And yes, it's been that way since new. As for the 3820, TCASE (66.8C) /= TCORE, all temps referenced are core temps. All specs are what the CPU microcode itself reports, also core temps. In old-school transistor terms it's TJunction temps, not Tcase temps & doesn't account for the thermal resistance of the heat spreader etc. The fact that neither of these CPUs are throttling also indicates they're well within SOA.

Has always been thus, AFAIK. I had always assumed it was a side effect of the craft file / tree structure... Now that you mention it, it does feel a bit like a bug. Damn you for pointing out something that never used to annoy me

Yeah, and $50 per incident did seem a tad steep to me , just sayin.

Ahh, so that's why I'm not seeing splashes.

"A posting designed to attract predictable responses or flames" (catb.org). IMO suggesting that people annoyed about the 64bit lockout should pay for the privilege of complaining could well fit the definition. If not taken in good faith, such could also be seen as a "specious argument" potentially for the purpose of annoying someone. (again catb.org & yes, I am that old ) OFC, given the current ambient temperature around the issue, almost anything could be used to incite flames in this thread...