steve_v

FWIW I've seen this too, on GNU/Linux x86_64. I'm going to wait a bit before attempting to reproduce it though, as half the mods I'd like to play with haven't been updated for 0.25 yet.

A seperate /home partition is a good idea, if you want to install a different distro or reinstall after lousing something up you can format the system partition with impunity & all your personal files will still be there. Just be aware that some installers (ahem, Debian) have really-stupid-defaults - make sure you assign sensible sizes. A swap partition is also a good idea, though it is possible to run without one or with a 'page file' like Windows does, having a seperate swap partition avoids fragmentation and allows you to position it on the fastest part of the disk - i.e. towards the outer edge of the platter.

Technically yes, there are a couple of ways to do this - but performace will suffer badly so it's not really a viable option for games. Nope As far as I know there simply is no GNU/Linux malware in the wild. Unless you get cracked, say via an open ssh server with a weak password, or runing a webserver with some dodgy PHP mess, there's pretty much no way for malware to get installed. Unlike Windows, where applications tend to come as binary installers (which could do *anything*, you don't know until you run it), Pretty much all GNU/Linux distributions use a signed repository or database of software compiled for the distribution by the maintainers. Trust in said maintainers is implied, but no potentially dodgy binaries from J. Random website. Any 3rd party stuff (steam springs to mind) is generally run with user priveliges - it could potentially trash your personal files (you do trust steam don't you but it can't infect the OS. If you're paranoid, or running a server you might want to install rkhunter or ckrootkit, which are about as close to an 'anti-malware' solution as you will find. There are antivirus products for GNU/Linux, but they all scan for Windows viruses. I have been using GNU/Linux fairly exclusivley since ~2000 and have never seen a rootkit, virus or malicious software package - despite running all manner of interweb accessible services, compiling a bunch of stuff from source etc. - I've even built a couple of 'from scratch' installs - lots of work, but a pretty good learning experience. Running Windows applications on GNU/Linux is possible, through such things as the Wine API compatibility layer or playonlinux. Some however are just not a happening thing so multi-boot or VirtualBox is still a good play. Check your Windows apps on winehq if you want to give this option a go, be warned however that Wine is far from perfect & some fiddling may be required. Of course GNU/Linux can access your Windows files and partitions just fine - the reverse is a bit more troublesome but still not a big issue. Most modern installers will shrink an existing Windows install & set up the boot loader for you, or you can do it yourself with a live disk like partedmagic. No reinstall required just do a fresh backup, boot the install media and grab a coffee. Also, as GNU/Linux tends to bundle all the kernel-mode drivers (monolithic kernel) so an install can usually be moved around from one disk or machine to another without the drama associated with doing this to Windows. Which distro to install is one of those 'how long is a piece of string' type questions - so long as you have the minimum versions of core libraries you should be fine. Unity requires libc version 2.15 or higher - a recent version of Ubuntu is probably the easiest (I don't like Ubuntu personally, but you might), IIRC Debian Wheezy (stable) ships a libc that is too old. Arch or Debian Sid (unstable) would be fine choices too, if you're willing to live with perpetual updates. I'm running Debian Sid as I type, and KSP plays just great. Obviously the bigger / more popular distros are likely to have better community support and a wider range of available pre-compiled software, but to a large extent *nix is *nix is *nix and it really comes down to personal choice - OSS and GNU are all about choice and freedom. If you haven't already, check out The-Linux-compatibility-thread. for known issues & which distros KSP is known to run on out of the box. There are literally hundreds of distros out there & there's no shame in 'distro hopping' until you find one that suits your taste, particularly as most come with a live disk you can boot and use without installing anything. Go have a look around on distrowatch, download a few livecd/usb images and give them a spin. None of your hardware looks like it would be a problem, do check the state of the GPU drivers in your chosen distro though, to get decent performance you'll want the proprietary closed-source drivers & historically AMD/ATIs Linux driver quality has been a wee bit suspect. YMMV regards Crossfire - I don't have any AMD cards though so you'll have to find out for yourself. You should be able to install onto pretty much anything resembling a hard disk, and several things that do not - if you want to put it on the RAID, check that there are drivers for your RAID card / motherboard FakeRAID Installing from USB media is the defacto standard these days so no problem with the lack of an optical disk drive. Seems I got beaten to it, oh well.

I agree, if it actually looked any better. Modern games: 'we have awesome post render effects' (Read: screenshots look mean) but the lack of real antialiasing makes your eyes bleed if you actually move around...It's like, why do I need a 512MHz faster CPU to get a "ribbon" instead of a menu bar? (ahem, orrifice) "Better" = Objective looks better (to actual players) not cause we (dev) said it looks better. "You need $$$ to play our game as it was meant to be" is not a badge of honor, more a poorly optimised game unless it actually looks better, in which case - prove it. I'm going to stop derailing the thread and go to sleep now

That KSP runs better with the OpenGL renderer is astounding... not at all. Why, oh why are so many games written for DX? Lemme see... Quake - performs better with OpenGL CryEngine - performs better with OpenGL Source Engine (Any) - performs better with OpenGL KSP - performs btter with OpenGL (Yes, thats us - surprise surpirise) Go on, I dare you to find one that doesn't fit the mold. Yeah, I get it, DX Is easier to code for,. But fu*k me, in this age, when poor performance = flames? WHY? Perfectly good open source cross platform GPU acceleration library and people still use M$ scond rate *****... Gah.

Auto overclock is EVIL and takes all the fun out of the process.

I just gave one of those away for charity/buds - it still cranks though - more than sufficient ffor KSP. Experience: My Antec 750W PSU will do ~820W for about 10 minutes before throwing in the towel running 1xGTX680+2xGTX560 in SLI. Go Antec

32bit binary numbers only go so high (32768 FWIW) 64bit numbers go higher. Every memory address needs a number... All modern CPUS are capable of 64bit adressing. When an application (ahem, KSP) doesn't do its own memory management and just says "I need this much RAM (in one block)" it has to fit within these contraints - otherwise it crashes with an 'out of memory/page allocation failure'. 64bit just lets you address more memory in one block. The KSP 64bit build (unstable on Windoze, stable on GNU, non-existant on MacOS) can address more than the 32bit limit, so you can run more mods On a side note, this is why it pisses me off when machines are advertised as having '4gb memory' and come with 32bit Windoze.. guess what, you can only use ~3.5GB of that... but I digress. I'm lazy and somewhat drunk, so http://http://http://en.wikipedia.org/wiki/RAM_limit too many https, gah. Further input shall wait untll the sunlight burns mine eyes again.

Higher clock speeds mean smaller margins, picture off -> on transition for a transistor/mosfet. If you increase the clock speed you decrease the time for each transition to be recognised, push it too far and a transition (bit) is missed = crashes etc. Increasing the voltage differential (VCORE) increases the magnitude/voltage swing of each transition, therfore you can go faster without missing anything. More voltage = more current = more heat = need a better cooler to keep things inside the SOA (safe operating area). Also, a state transition is not instant, each transition from a '0' to a '1' or vice versa involves some time spent as 'in between'. If you're not a perfect conductor (1) or a perfect insulator (0) you have resistance. Resistance = wasted power = heat. The faster you go, the more heat generated. Um... no. double no. What I mean is that your body/environment can generate some pretty horrendous voltages - don't transmit them to your expensive toys. Be carefull to ground yourself or get an antistatic wrist strap. I work with 'live current' all the time - voltage kills sensitive CMOS parts, current frys bags of mostly water. The difference is subtle but important. Clarification: If you want to run lots of mods (read >3.5GB memory usage) you will need a 64 bit build - the Win64 build is unstable as all get out, the GNU/Linux x64 build is stable but the mono runtime is slower than its windows counterpart.

OK, so I'm probably being a ..... but... THIS! I keep thinking I might be able to be helpfull, despite not being in the know, but without logs you might as well reference folklore and magick. 'stuff doesn't work' is pointless and just clutters the thread like i'm doing right now. The latest dev build works great in 0.25 (for me at any rate, aren't I lucky) post logs if you have issues, that way bugs can be found and squished. MechJeb taught me how to fly. Thank you.

'Are we there yet?' ad infinitum gets pretty annoying, just sayin'.

Whut? really? where's mine? I want cats Ok, so yeah I'm bored waiting for 0.25 mod updates

Yus! you just saved yourself a ton boring reading. I've been waiting for everyone to do this. One day, Win64 will be stable, but not today. Now the real bugs can be sorted from the chaff.

My 2c? Get an Intel with the highest per core clock you can find, buy a decent cooler (IMHO, air is still king unless you spend big) & an 'enthusiast' board. Then OC the tits off of it. The clock speed race seems to be over, now it's all about cores. Unfortunately Unity is single threaded If you're lucky, and determined, you can get ~4.5GHz out of most i5/i7 chips on the right mobo. Cache size *might* have a small impact, but I doubt it. Ram bus speed will impact load time, but not nearly as much as a decent SSD will. As far as GPUs go, M stands for medicore. KSP however is surprisingly light on the graphics. NVIDIA cards that end in less than *50 are probably not worth the time as they tend to be budget or mobile chips. (for ref, the AGP 8800GTX I just gave away to a good home mauled KSP & it was seriously old by PC gaming standards) As for RAM, KSP shouldn't use as much as it does... but it does. (please, for the love of Dog, fix the asset loader) Any more than 16GB is excessive. Use ATM or GNU/linux x64, the Win64 build is awfull. Unfortunatley the GNU/Linux Mono runtime is also awfull - pick your poison. Generaly speaking, you put the thing in the hole that it fits in, it's not quite idiot proof, but if you can do Lego you can build a PC. Just ensure you ground yourself before grabbing edge connectors with your 1000v hands (I have nylon carpet - do you?) Days gone by you could put a CPU in backwards and let out the magic smoke, now everything is keyed and not nearly as much fun. IMHO, (I can smell the napalm coming) fancy thermal grease is overrated, I use ordinary unick industrial thermal compound - no silver, no magick. The same kind as is used for the SCRs in big angry 500KW+ kill you if you look at it funny inverters.

They do. The engines at any rate, YMMV. There's gonna be a fair few part mods un-fixing bugs that are now fixed in stock. Chur for the word on AIES though, might be worth putting a word in on the official compat thread if you haven't already... help out the other impatient players an' all

Didn't sound like a command to me. Having resisted the urge to bug modders all day, and run out of mods to check up on, I'm going to watch some ST:TOS Damn fine suggestion IMHO.

Shiny, very shiny indeed. So far so good, only a couple of minor issues to report: Appears that 'asteroid size' resets on load / scene change? Mining a largish (1996t) rock, converted some 3000000units / 500t to empty space. Switch to space centre and back - mass reads 1996t again, though empty / total space values are ok. When working with large asteroids (bigger is better, right?), the default increments on the 'vent rock', 'expand tank' and 'compress' buttons are pretty hard on the rodent... Confirmed here. On another note; Is there anything special I need to do to add new resources to fuel hatches? A blind guess (before finding firespitter docs) gave me: @PART[HA_FuelHatch] { @MODULE[FStextureSwitch2] { @textureNames ^= :$:;ART/FuelHatch/Ka;ART/FuelHatch/XE: @textureDisplayNames ^= :$:;LiquidHydrogen;ArgonGas: @fuelTankSetups ^= :$:;4;5: } @MODULE[FSfuelSwitch] { @resourceNames ^= :$:;LiquidHydrogen;ArgonGas: @resourceAmounts ^= :$:;0.0001;0.0001: } } It appears to work, though I'm far too lazy to make new textures just yet. Close?

Because the Win x64 build is far too unstable for mod authors to support, i.e. random crashes even with _no_ mods installed. That's not to say these mods won't work on x64, but if you have issues / would like support you will need to reproduce the problem on the 32 bit build. So.... do you have this problem with 32bit + ATM? I don't see anything in common between your crash logs, certainly nothing mod-related. How much RAM is KSP using when this happens?

Got any system logs? Can you ssh into the hung machine? Does Ctrl-Alt-SysRq-k (or more aggressively -i) get you a console, and thus a log? I too would suspect the GPU driver.

As much as I would like to unblock ads in support of the forum, I will do so when they conform to these guidelines and not before. Same goes for any other site, as such ABP is on most of the time. I disabled adblock (here) yesterday and was immediately presented with a bright, flashing 'download pc-fixer now' type scam - ads re-blocked.

Excellent! always nice to know I'm not imagining things

They certainly do, but it looks like nobody's listening. Try the .cfg from 5.0, I liked it better but YMMV.

Pwings does have some wingtips, when not using those I usually use winglets. You should probably get Pwings anyway though, it goes real nice with this pack and helps to avoid part count bloat and wings snapping off large craft

Now I know I promised not to complain about the gear any more, 5.0 was sweet. But... skipped 5.1, just loaded 5.2: My previously working craft are *sliding sideways on the runway*. Landing is now an extremely dodgy proposition. Either braking traction is somehow un-even or the runway just got super slippery. Dropped the .cfg from R5.0 back in and all is well. Repro: Launch, apply brakes, watch nosewheel slide sideways Am I doing something wrong, or is the latest round of gear changes heading in the tokyo drift direction?

How about fitting some deployable airbrakes to reduce your airspeed to a safe value?