skeevy

Here's the relevant part of the OP you forgot to scour....it's in-between the Pictures and Credits sections.... Dependencies Core Pack B9AnimationModules plugin by blowfish B9PartSwitch plugin by blowfish Firespitter plugin by Snjo and RoverDude ModuleManager plugin by ialdabaoth and sarbian RasterPropMonitor by Mihara and MOARdV SmokeScreen plugin by Sarbian Legacy Pack Depends on the core pack and all of its dependencies (not included in the legacy pack download) HX Pack B9AnimationModules plugin by blowfish B9PartSwitch plugin by blowfish ModuleManager plugin by ialdabaoth and sarbian SmokeScreen plugin by Sarbian

Download and install the 1.3 versions of all the B9 dependencies listed in the first post (I used CKAN for this step) Download the current 1.2.2 version manually. Open the B9 zip and copy only the B9_Aerospace into the KSP GameData directory. That's it. The same steps apply for the HX parts. This wouldn't be necessary if B9 didn't bundle its dependencies. Sort of related and could probably have its own topic, but I don't like it when mods bundle dependencies. I've had so many issues with CKAN and mods bundling dependencies that it isn't funny. Install "Mod A" and it has the latest MM dll bundled with it, two days later install "Mod B" and the mod maintainer didn't update the included MM dll so my local MM dll gets downgraded and I didn't even know it. CKAN aside, it's still a problem for inexperienced mod users because they'll blindly drag and drop crap. I understand why they're bundled (people are dumb and don't read the post(s) with the instructions), but when the mod is using a centralized repository...... Sorry, had to vent that. This issue is always the worst whenever KSP updates and I've had a "fun" time dealing with dependency bundles.....Oddly, B9 wasn't one of them because I had enough sense to read the OP and the posts in last two pages. Unfortunately, not all mods have detailed posts detailing the update\bundle got ya's.

Mine was April 2014.....I have the month right, does that count?

License and upkeep aside, ZFS is pretty good. BTRFS with BFS is pure suck. Haven't tried it with deadline, noop, or CFS yet. I used to run XFS exclusively until a random power outage corrupted my drives and I lost around 1.5TB of music, movies, games, and backups. XFS does not like losing power, especially during massive file operations. Haven't played KSP since my last post here. Been busy IRL and haven't had the time. I did pick up the game Verdun from Steam and managed to get a few hours in it. Just wanted an FPS and figured I'd support another up-and-comer as well as wanting a WWI game. WWII and Modern games get old after a while. I'd love a good FPS set between the 50's and 80's....1900's and 1800's btw...not that many good Cowboy, Civil War, Korea, or Vietnam games. Verdun's not bad, but it's obvious that it's a WIP. Needs more North American players (hint, hint). Bolt action deathmatch is a blast if there are a lot of players on the server. Same GPU that I have. The 25fps could be from V-Sync being enabled in combination with physics calculations. I had that issue too and those were the causes of it. Sadly, I could either get 25fps constant like that and stay in the Yellow no matter what or disable V-Sync and lower my physics calculations a bit and jump between normal and yellow with the framerate jumping between 9fps and 45fps depending on where I'm looking, where I'm currently at (orbit, Mun, launchpad, etc) or if my trajectory leaves the planet or not -- not sure why, but the second my trajectory exits the atmosphere I gain a massive FPS boost regardless of what's going on. If you can, run a 3.17 kernel and update Mesa to 10.3. You'll get a decent increase in performance. If the AMD Radeon development keeps on like it is, we should have some awesome drivers around the 3.19 or 3.20 kernel releases. It looks like AMD missed the deadline to get the AMDGPU driver added to the 3.19 kernel. Hopefully Mesa 10.4 and Kernel 3.18 will be released soon and we'll be able to use those (Mesa 10.4 due in December IIRC; Kerenl 3.18 was RC3 the last time I checked). Bonaire is the codename of the R7 260x. Thought I'd let ya know. I'm gonna be a bit pissed off if AMDGPU (the upcoming new opensource radeon driver) doesn't support our card since they're doing in-house testing with GCN 1.1 cards like ours. Rumor is that AMDGPU will only support GCN 1.2 and up (R9 285x is the only GCN 1.2 card at the moment). EDIT: @sal_vager Like the new OS tags and colors on the support pages

Linux user with ATI card (MSI R7 260x 2GDDR5) -- either run with xserver 1.15, kernel less than 3.17 and Catalyst 14.9 or xserver 1.16, kernel 3.17, and radeon driver (or use the Ubuntu 14.10 Catalyst 14.6 tweaked to use xserver 1.16...IMHO, radeon with kernel 3.17 is better than Catalyst 14.6). Either setup works decently enough...AA might not work, but that's about it really.

Most of my experience is setting them system wide or user wide, like in bash_rc or /etc/locale, /ect/env...places like that. KSP is the first time I've actually exported an LC command on a per-app basis, and honestly, I never bothered checking to see if it was being set system wide or not afterwards (a case of if it works, don't fix it anymore). I should know better than that...

Only reason LC_ALL=C is being set is because that's the recommended fix in the unmodded Linux thread. Did a bit of searching and LC_COLLATE and LC_NUMERIC have been used to fix the period and comma issue for different things. Arch Linux used to set LC_COLLATE=C system wide to act as a hacky fix for similar multi-language and sorting issues. One or both of those would probably be a better fix than LC_ALL=C system wide. Another option would be to determine what LC options the current system is using (run "locale"), stash those aside, set LC_ALL=C while KSP is being played, set system's original LC_* settings when KSP is quit. Thinking out loud here, but @Fail-Man 3D's script combined with my 2nd idea (locale backup/restore) and an automated git solution for backing up save games and settings would be nice to have -- think about it -- mods and mod ships (like with FAR) won't be polluting the game's directories so the KSP directories themselves would always be stock, LC_ALL=C while playing and original locale(s) restored upon exit, and backups of every save, autosave, and settings when they're changed or created. Thoughts or ideas? And yes, I can see issues arising if KSP crashes and the script doesn't catch that to restore the LC settings. Can't believe I forgot to add two "export"s in those scripts....red for syntax highlighting goodness (before this thread, had everything in two lines; made it a bit more human readable and screwed it up....thanks for catching that; had to color export red because the syntax highlighting is why I screwed it up...saw those lines had correct colors and completely brain farted that export was missing)

AUFS and ZFS are different file systems like FAT32 or NTFS, only much more advanced. CK are kernel patches made by Con Kolivas. BFS stands for brain f*ck scheduler and is an alternate IO scheduler to use instead of CFS (completely fair scheduler). Traditionally, Linux stuff is programmed for server use, but CK patches and BFS are more for desktops/workstations. For a new user, none of this is anything you should be concerned with (unless that script above gets tweaked to use AUFS....which is a possibility because I dislike dealing with dumbass r/rw errors and some mods do need to write to their directories (like ATM or Parts Catalog)). To install Linux and just play KSP....the easiest way is install Manjaro (or any distro really) to it's own hdd (one OS to a hdd is my philosophy; post if you need help), boot up, run as root "pacman -Syyuu", reboot, run as root "pacman -S steam-native", launch Steam, download KSP, Play. If you don't use Steam, after the first reboot, go to KSP's download page, download, extract, then play it. To put that in Windows terms: install it, boot up, update the system, reboot, install Steam or Downoad KSP...Except for graphics drivers, you hardly ever install any driver on Linux; I will note that WiFi cards are an exception to that. As far as Manjaro and Ubuntu installers are concerned, they're click, click, set up partitions, click, click, fill out user info/hostname/etc, click, click, done. Everything is WYSIWYG and real straight forward. It took me under 20 minutes to install Manjaro to its own hdd, maybe another 20 minutes to configure it, install Steam, and start playing KSP. If you're gonna install Linux to a HDD containing Windows, it isn't as easy but it is possible (though not really recommended). Instructions are different depending on Linux distro, version of Windows, BIOS or UEFI, etc. I don't know what basic instructions you've been reading, but patching kernels usually isn't necessary except for things like CK, AUFS, BFQ, and other things that most new users just don't need to be doing or aren't part of the mainline Linux kernel. Those shell commands....that's just basic system maintenance. A lot of that stuff can be done with a GUI app, but what you gain in convenience is a loss for fine control over what you're doing. For modern Linux setups, about the only thing you might have to configure is xorg.conf if you have some odd ass setup in regards to your GPU. If you want, link to what guide you're using and we'll try to simplify it for ya. I advise Manjaro, but only because, for new users, it has a lot of advanced functionality and features that actually require things like kernel patches and whatnot; it has that steam-native package that makes Steam use system libraries (the cause of a lot Steam Linux KSP issues is using the Steam libs); and it's really up-to-date -- there are only a handful of distros more up-to-date than Manjaro, and that handful of other distros come with a steep learning curve -- see here for an example of a steep learning curve. EDIT: just checked the BFS link....the forum cuss filter changed the F word to .... so replace the .... in the link with the F word. EDIT2: Have 4 more episodes of Star Trek TNG left. Kinda in a marathon of them so I may not be back for a few hours or tomorrow.

I'll look into it on and off throughout the next few days. I don't have the ability to run two monitors like that...my only two are my 42" 1080p TV (main monitor) and an old 1280x1024 (I think, been a few years) LCD 17" monitor...so the best I can do is Google and provide links. If I get the chance (and find a spare HDMI cable) I'll lower my main monitor's resolution down to match my old LCD monitor and experiment around with it. You should be able to tweak xorg.conf mixed with some xrandr magic to accomplish this; probably have to add in some virtual desktop modes into xorg.conf. Been a long time, but I did manage to get it working with Ubuntu 9 (or 10) with my old laptop, but that laptop really sucked and the onboard intel GPU didn't like doing it, so I only bothered with it for maybe two days 5 or 6 years ago. EDIT: This link may help with some of the xorg stuff I'm surprised the Xinerama settings in AMDCCCLE don't automagically do this for you. It shouldn't be any more than to configure it all in CCC & reboot.

That's awesome. It's like Skyrim Mod Organizer, only for KSP Linux in the form of a script and A LOT more manual. Nice. Anyone want another +1 for Manjaro? Nope? Well, too bad, you're getting it anyways -- Their stock kernels come with AUFS support (and ZFS support if that interests anybody). No patching required (at least on my 3.17 stock Manjaro kernel). They also come with some CK patches and BFS stock. Unrelated to that, just something I've been thinking about lately Now we just need a universal image conversion script for DDSLoader. I've been looking into it, but unless someone explicitly lays out what coverts to what, what needs to be skipped, what images need to be flipped, etc, I'd just be pissing into the wind. There's a lot of information on the KSP image formats spread throughout the DDSLoader thread and it's a lot to take in all at once. @Todacious has a basic Linux script and @Shaw has an img2dds program for Linux.

Multimonitor isn't really my thing. I haven't ran multimonitor since Win2K because it was weird having a 19" 1280x1024 LCD MM'd with a 42" 1080p screen or that same 19" LCD with a 17" CRT @ 1024x768 (remember when x768 was the cutting edge, top of the line HD resolution?). Did a bit of Googling and found multiple XFCE solutions. If you're running the latest XFCE version, it has multimonitor support built into it. Just go to XFCE Settings>Display to find them; located at "Start">Settings>Settings Manager>Display & "Start">Settings>Display on my system. XFCE Display Settings disper arandr AMDCCCLE If you have to use a command (or a script) like xrandr, just remember to set it as a start up option. That's in the same settings menu as Display, just scroll down a bit to Session and Startup.

Agreed and why I ended up ditching Ubuntu....for the hundredth time. You don't even have to patch manually with Arch. Add in the archlinuxfr repo for yaourt, and it's as easy as "pacman -S yaourt" followed by "yaourt -S catalyst-test". Much easier than doing it manually from the AUR with pacman and buildpkg. Manjaro is Easy-Mode Arch Linux. GUI Installer, click, click, click, done. Also has a GUI package manager with AUR support (do not use the GPU drivers or Kernels from the AUR with Manjaro; breaks mhwd, Manjaro's kernel and driver installer). If you like Arch but don't feel like doing everything "The Arch Way" or from scratch, Manjaro is a decent alternative. Ditto with Arch Bang, though it's pure Arch so you'll just get an easy install and have to know what you're doing afterwards. If you've ever ran Arch and broke you entire system with a "pacman -Syu" that forced you to start over, you'll appreciate Manjaro snapshotting Arch and fixing it ahead of time. EDIT: If you go with Manjaro 8.10 XFCE, on first boot you need to fire up a terminal as root and run "pacman -Syyuu" to fix a few broke things since the installer is a bit old (haven't ran one of the newer RC isos for the upcoming releases). Gah....just got some updates that require an hour+ for compiling (wine-rt and some LXQT git packages from the AUR...I need to add the pipelight patches to wine-rt...not today cause I feel lazy).

@Eiktyrner If I'm reading this correctly, you're trying to triple monitor with an HD 5870. Unless your CPU hits the 4ghz+ range, I don't think you'll have much success with that. My CPU runs just below 3ghz and struggles to play KSP at 1080p on a single monitor with a GPU that's a few generations newer than yours. That Tear Free setting in CCC is just Vsync on crack and really isn't worth the performance hit when playing games. It's fine for watching movies, web browsing....anything but games; unless you can run that game with a 60+ FPS constant before enabling Tear Free because you can lose half your framerate with it. KSP on Linux runs slower than KSP on Windows on the same system. Unless you have a really good system with resources to spare, which to me would be a quad core or better CPU (freq really doesn't matter for this tweak) and 8GB+ ram, things like Compiz, KDE, XFCE's Compositing tick box, Unity, and Gnome 3 shouldn't be used. If you have a quad core or better, you can always force KSP off the main thread and to two less used cores to mitigate system CPU cycles used. See my script posted at the bottom of the OP on The Other Linux Thread for more details. If you have a file system like BTRFS or ZFS, disable compression on the partition with KSP. BTRFS compression sucks anyways...at least when compared to compression with ZFS (speed and amount compressed). On the drivers -- only bother with the Radeon driver if you're running a 3.17 kernel with Xorg/Xserver 1.16 and Mesa 10.3+ (those combined have some good Radeon enhancements). If you don't meet that, stick with Catalyst 14.9. I can already tell you're running a 3.15- kernel with Xorg 1.15, probably Ubuntu 14.04 as well, just by you saying you're using the 14.9 driver. Without patches, 14.9 only runs up to kernel 3.15 (maybe 3.16) and isn't or can't be patched for Xserver 1.16. There is a Catalyst driver for Ubuntu 14.10 based on Catalyst 14.6 that does support 3.16 kernels (3.17 with AUR patches) and Xserver 1.16. That Ubuntu FGLRX is what I'm using with Manjaro (it's Manjaro's default Catalyst driver) because it's the only Catalyst driver that supports bleeding-edge systems. Here's a link to Arch's Catalyst-Test driver if you feel the need to patch it manually so you can run Catalyst on a bleeding edge system.

Your only options are lowering graphics settings, running with opengl, and using Active Texture Management; well, and switching to 64 bit KSP on Linux. Other than that, all you can really do is hope Squad either fixes the current Windows 64bit version or moves to Unity 5 and hope that 64bit works better with it.

Hmm. That is odd...action groups work just fine for me with my qwerty keyboard. And I thought action groups are what you meant...just wanted to clarify. Do us a favor. Play KSP, hit a few action keys, and post both of the logs. Maybe we'll get lucky and find something in it. Perhaps try Action Groups Extended if all else fails, it may help (guessing at that, but it's a mod I use regularly). It was the damnedest thing with my shoulder...all I did was press down with my left arm to stand up and it was out for a few days. Feeling better now so I can actually sit in my chair and use my PC for more than Netflix. See the OP of The Other Linux Thread under modded installs. On the bottom are some start-up scripts for KSP that are optimized for both Nvidia GPUs (but work just fine for AMD GPUs) and multicore CPUs. Another tip, don't lauch KSP from within Steam -- you'll be using old Ubuntu 12 libs when you'll be better off using your native system libs from starting KSP outside of Steam. Unless you're using something likes Arch/Manjaro's Steam-Native package, never start Linux KSP from within Steam. Last thing, the more up-to-date your OS, the better KSP should run (in my experiences at least; and why I recommend Manjaro over Ubuntu these days).