steve_v

Must be a big kitchen, if you have to hunt for the fridge

Amen, recon there's an eponymous law for that somewhere. Vexx's law, anyone?

IME the stock Intel cooler is sufficient but no more. Idle temps are about what I'd expect if some kind of fan controller is in play, 50C die temp is a common default target. So long as you stay below the "high" and certainly below the "crit" temps for your chip you'll be fine. Mine (i7-3820 @4.3GHz) FWIW: Idle: 48C (~32C with fan at 100%) Load: ~72C. Chip spec: "high": 80C, "crit": 100C I also have an old Q8400 (@3.2GHZ) that will occasionally hit 80C under load on a hot day (mainly due to a very cramped case), it's been doing just fine for years. Must get around to cleaning out the cooler on that one though, 'tis summer again here.

3 minutes has got to be some kind of record You're welcome, enjoy.

Klockheed Martian SmartParts?

On the good faith assumption you are not just trolling: Who is going to police such a system? Asking for money is a huge can of worms. I doubt it would improve the SNR in mod threads anyway, since somebody will still have to sift through a bunch of 64bit bugs. Preventing this is the whole point of the exercise. People still won't read the OP, and will complain even more loudly when they discover there's a price attached. The status quo: From the users point of view, just replace the monetary concern with effort. Step 1: You want to run mods on the unstable Win64 build? learn how to compile a mod & maybe a little bit of C# along the way. Step 2: You now have the experience to triage your own problems rather than wasting mod authors time & filling productive threads with noise. Step 3: Profit from your newfound knowledge by finding real bugs, or even go to the next level and develop your own mods. Step 4: Help others to do the same.

That should roll slowly down the runway even with no thrust at all, as KSP planes do. If it's not then there's definitely something fishy going on beyond just a design problem... What mods 'ya running?

Heh, not on GNU/Linux it doesn't *messes with fancy compositing desktop effects while KSP loads*

Err, alt-tab out and see what's new on the forum. i.e. right now. Or make coffee

The one overriding factor for KSP performance ATM (Come on Unity 5...) is single-threaded CPU performance, as such, go for the fastest Intel CPU you can find. Intel integrated graphics should be OK, but a mid-range discrete GPU will be better. And, yeah, Macs are shiny and all but you'll get better specs per $ building a PC... you can even run is as a hackintosh if you can't part with OSX

Update to the latest KJR dll from github, the current release has... issues. Namely, sticking certain parts to worldspace on load, this can be somewhat spectacular. For times like this, I recommend S.A.V.E., cause, ya know, backups are good

I usually just eyeball it TBH, most of the things I land in atmo can fly in atmo at least long enough to make up the difference

16GB, 64bit, NVIDIA 346.22, not that that appears to make a difference.

Excellent Please, let it ever be thus.

That would be handy, especially as the contract target tends to get in the way when setting surface targets or creating nodes for a manual(ish) landing.

If it's what it I think it is... welcome to the club, it does this on GNU/Linux also (& I have very similar hardware). I was wondering if it's like that on Windoze too, now I know Same with both DirectX & OpenGL? Assuming it's not some background process, or as wibou suggested, disk I/O (in my case it's not AFAICT, also KSP loads everything into RAM anyway); Worse with mods? Worse with higher part counts? Otherwise silky framerate? The only thing I can put it down to is Unitys garbage collection, not really something anyone but Unity can fix. There's much complaining on the Unity forums... I had a go recompiling Unitys mono build with multithreading enabled for the garbage collector - it practically eliminates the freezing but also introduces a nasty memory leak If anyone has any better ideas I'd be all ears, it's very annoying.

Probably not, MechJeb simply doesn't know how to account for atmospheric drag in FAR.

I am envious of your CPU It'll OC better than mine.

Just for the record, what version of the catalyst/fglrx driver are you now running? A fair few others have had similar problems & if upgrading is a fix... well, it might be good to know

A jet producing any thrust over 2000m/s is pretty unrealistic, if you really want turbojets to work like they do without FAR, just comment out (or tweak) the nerfs starting at line 694 in FerramAerospaceResearch.cfg. It'll be pretty OP though. Also, check your drag. - turn on "show aero forces" in the FAR setup menu and look at various parts in flight. As jet thrust falls off drag becomes your biggest enemy, especially with the new skin friction model.

You may also want to consider a bit more tail / vertical stabiliser since in the thin air at those altitudes aerodynamic stability can get a little dicey, especially with those draggy intakes (presumably) foward of the COM. But yeah, asymetric thrust. From looking at your pics I would say your starboard engine is loosing thrust - throttle back more, move the jets closer to the midline (bicoupler?) or add yaw authority. Not impossible, just counterproductive since with FAR the added drag from more intakes quickly overwhelms the decreasing thrust from jets at speeds >mach 3.5 or so. One ram intake per engine ought to be enough for most designs.

[RANT] Yeah, that. It's unfortunate but it's true. I remember when the NVIDIA driver was pretty bad (been using GNU/Linux since ~1998), but it was never as broken as the AMD drivers are now. It's been one thing after another - not updating to support current Xorg, dropping support for older GPUs etc. For a while there several distros were maintaining a whole xorg branch (and all the other linked code that implies) just to have a working AMD driver. That, and the fact that AMD haven't made any attempt to support other the *NIXes i.e. FreeBSD make me pretty unlikely to ever buy an AMD product again. For the record, I had a similar experience "upgrading" my old GTX9800. I can't recall the exact model AMD card, but it sounded like a hovercraft, performed like a stoned pig and was returned within a day. [/RANT]

It's really on AMD to fix that hunk of junk driver, about all you can do (aside from gettting an NVIDIA card ) is maybe try the latest beta. I believe there's a PPA for it, but I don't actually run Ubuntu so you'll have to have a look around.

There is also voglperf which, as well as a rather ugly OSD, can do other fun stuff like dumping frametimes to a CSV file for feeding to GNUPlot etc. Or grab fps.dll from ksp-devtools, which should work on all platforms. glxgears is just an old OpenGL demo, often used to check if GL is working but not really usefull for anything else.

Realchutes version? Sounds like the same issue reported here, thought this was fixed though. All parachutes appear in both utility & parachutes categories for me too, I had thought this was normal? It doesn't cause any issues here anyway.