steve_v

We keep sayin' it, and people keep refusing to believe... 'cause dual booting is just way too hard. Interesting that there is actually some GPU passthrough on the big iron, wonder when it'll make it to consumer stuff... I don't get to play with toys that expensive KSP actually runs in VirtualBox, I get.... wait for it - 3FPS, yes 3. Don't try this at home folks, it's just not playable. EDIT: 3 FPS *on the menu screen* ingame is more like 1.

FAR nerfs the jets to a more reasonable power level, and adds an approximation of RL maximum airspeeds, so most jets will die at ~mach 3 like they really should. Less fine-tuning, and perhaps a little more leeway for the crazy. NEAR won't break your plane so much, but it will still need to be at least airplane shaped I guess it depends on your expectations - RL aircraft follow practical design rules for the same reasons they do in FAR/NEAR, stock aircraft don't really look or work like RL because the aerodynamic model is, um, 'creative'.

VirtualBox has OpenGL, but VRAM is limited to <=128MB, so uh, that's probably not going to work so well. Not sure what the deal is in VMware, anyone care to try it?

I actually get *slightly* better framerates in Windows - I put this down to mono on GNU/Linux being somewhat slower than .NET, at least according to all the benchmarks I have seen. Bugger. I'll add it to my personal list of 'reasons to resist installing steam' EDIT: One version back, same as the KSP store then .

And If the situation were reversed, 'just install windows' would be a less dodgy proposition to someone who had never used it before? Partitioning is much the same whatever OS you run & Gparted is every bit as 'noob friendly' as Windows disk management. No, but I *will* laugh if they didn't do a backup before mucking about with the primary hard disk layout.Partitioning is just one of those things that can nuke your disk, regardless of what OS you do it from, the warnings on pretty much every partitioning tool under the sun make this very clear. Bugs happen, it sucks. I've given up on MS fixing the 'bug' that only allows installing on the first disk in the system and nukes the MBR without asking At least the *buntu installer makes _some_ effort to play nice with other OSes on the system, even if it is broken at the moment. Yeah, really-stupid-defaults strikes again. Also, 5GB for / on a desktop is probably asking for trouble... I've been doing exactly that just recently & on this very forum.IME setting up a non-oem Windows install & getting all the drivers installed is _more_ work than setting up a non-oem Linux/BSD/Solaris etc. install. The issue is preconfiguration not OS type, so complain to your hardware vendor. If you're willing to put in the time & effort to learn KSP, installing an OS shouldn't be all that hard. Then I guess I have grossly misjudged the average competency of 'most people here' - you managed it did you not? Seriously, we're all running a game that is *still in alpha*. Having to do a little work to dodge bugs and get to the awesome is to be expected - installing a different OS is just a larger-than-average workaround.

Purchasing through the KSP store gives access to the current + previous release, on all platforms. Dunno about steam. Drive issues? not sure what you mean there, but a GNU/Linux install just needs a partition, preferably 3, on any disk that can be booted (and is large enough OFC). - there are some gotchas if you use UEFI/secure boot but google has you covered.

For the impatient: the current 'live' branch works just fine in 0.25. (for me at any rate, YMMV) Go look on the bitbucket repo and you will see that the required libraries have already been updated.

Yup, but you're not gonna like it: GNU/Linux x86_64 *on bare metal* runs sweet. My KSP RAM usage is ~6.5GB with many mods, no ATM & no crashes. The Windows x86_64 build *should* be able to address more than ~3.5GB, but it's a horrible buggy mess at the moment so just don't go there. Gaming in a VM will be disappointing as only rudimentary GPU acceleration is available, if any.

I think you may be right I had the same happen after premoving AJE with related 'part test' contracts active, so it's not RealChute specific. - Unfortunately logs long gone now.

This Using Windows for any length of time makes my head hurt, I soon find myself missing the flexibility and all the little tools that come with any *nix OS by default. It's got be be a *very* good game to convince me to boot into Windows - even then I try to avoid interacting with the OS, or even seeing the desktop for that matter. I would do it for KSP, fortunately I don't have to. Besides, GNU/Linux has stable x86_64

The Linux beta dll doesn't load for me: AddonLoader: Instantiating addon 'AdvancedFlyByWire' from assembly 'ksp-advanced-flybywire' (Filename: /BuildAgent/work/d63dfc6385190b60/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/kernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32 Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/./libkernel32.so Fallback handler could not load library /home/steve/KSP_linux-0250-FAR/KSP_Data/Mono/x86_64/libkernel32 DllNotFoundException: kernel32 at (wrapper managed-to-native) KSPAdvancedFlyByWire.Utility:LoadLibrary (string) at KSPAdvancedFlyByWire.Utility.CheckLibrary (System.String fileName) [0x00000] in <filename unknown>:0 at KSPAdvancedFlyByWire.Utility.CheckLibrarySupport () [0x00000] in <filename unknown>:0 at KSPAdvancedFlyByWire.AdvancedFlyByWire.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelWasLoaded(Int32) (Filename: Line: 4294967295) Full log. I sure don't have those libs. Debian sid KSP 0.25 x86_64

I would agree on this one, there's pretty much no reason not to run x64 (x32 binaries will still run just fine), unless perhaps you're running with <2Gb RAM.

@ POGtastic: Any errors in your logs? If you're sure your download is ok, check permissions in your KSP directory: 'find ./ ! -user [username]' (replace'[username]' as appropriate) Try updating your GPU drivers; Nvidia 343.22 work just fine for me (Debian Sid). Smxi may be of intrest here, esp. if you want to try the betas. AA works fine too, when set to 'override' with nvidia-settings.

Despite being fairly old, according to the AMD site that's actually the correct driver version for RadeonHD 4xxx cards. For some unfathomable reason AMD dropped support in the later drivers. Of course, not having an AMD card myself I may be reading it wrong.

Just guessing here, but is your executable actually marked as executable? try (from a terminal, in the KSP directory) chmod +x ./KSP.x86, then ./KSP.x86 Ignore the launcher Also, check that KSP.x86 is actually something that _can_ be executed - ldd ./KSP.x86 should output a bunch of libraries, if it just says 'not a dynamic executable' there's probably something wrong with your download...

"KSP_x64.exe" There's your problem. As has been covered again and again and agian... KSP_x64 is NOT stable on Windows. It was bad with 0.24.2, it's essentially unplayable with 0.25. You might be lucky, you might not. Most likely it will just crash for no apparent reason. If you must use it, look here. Otherwise, try the 32bit build.

All of the above

Mkay, as a native UNIX neckbeard speaker (I haven't used windows for more than 10 minutes at a stretch in at least 8 years) I suspect I will have as much difficulty translating out of 'klingon' as you do in reading it Note on Google: years out of date misinformation and context-free command-line snippets abound, try searching the ubuntu community forums and wikis first - if you don't understand or can't find the answers you need, post in the newbie section and be patient There tends to be a bit of intollerance for people who have not done any homework regarding basic GNU/Linux concepts, or expect things to work just like Windows. It's not nice but it happens, I too am guilty of this at times. Don't let it get to you. Sounds to me like you're a Windows 'power user' used to knowing what you're doing - I feel your pain every time I have to use Windows and can't remember how to do basic tasks I can do in *nix without thinking about it. Trust me, it will come. I will do what i can to help out, but I can only go so far: I don't have a copy of VMWare to work with. I am _not_ booting into Windows to do this - like you I have 'always on' software i.e. the ssh tunneled remote desktop I'm typing this in, therefore you will need to do some experimentation yourself. Patience, you'll need to un-learn much of what you know. "but... still dead end." _really_ doesn't tell me anything, did you try the "additional drivers" wizzard? if so, what did it detect & where did it fail? Did you try 'apt-get install open-vm-tools' and 'apt-get install open-vm-dkms' on the command line? (from the wiki I linked) if so, what output did you get? If you get 'permission denied', prepend 'sudo' (Super User Do) to the above commands to 'run as administrator', little details like this are often omitted under the assumption that you already knew that Hint: apt = Advanced Packaging Tool. If you run a Debian based distribution i.e. Ubuntu, sooner or later you will need to learn how to use it as it's the primary means to install or remove software. The GUI tools are nice, but they're just calling apt in the background to do the real work. Repeating the sounds is fine, but you need to tell me what the reply was Installing the vmware drivers *should* solve all your immediate woes, but there's a bit of a disconnect from the Windows 'visit website -> download -> run installer' to the GNU/Linux 'tell the package manager what you want to install and have it fetch it for you'. It doesn't help that proprietary vendors are notorious for NOT doing things the *nix way - leading to multiple confusing ways to achieve the same end . FWIW, I just fired up xubuntu 14.04 in VirtualBox to make sure I'm not feeding you BS, I get a nasty little 640x480 desktop too. The "additional drivers" wizzard correctly detects that I am running in VBox and offers the VirtualBox tools as a driver for selection. Select driver > apply > enter password > reboot VM gives me a nice resizeable desktop at whatever resolution I want. I suspect VMWare will be much the same. Ok, so IMG tags don't appear to work. This is what it looks like for VirtualBox. Edit: Where did my edit go? This is what installing the VMWare tools the old school way (apt on the command line) looks like. Of course it won't actually load the drivers for me since I'm not using VMWare, but you get the picture.

If you're only getting 640x480, its probably because you're running the generic VGA runs-on-anything-post-1993 xorg driver. As mentioned elsewhere, AFAIK you cannot use drivers for your real hardware inside a VM as the guest OS can't see it directly anyway. Unless of course VMWare has some new magical passthrough thing, been using VirtualBox for a while now. Try vmware-tools, either through the 'All Settings' -> 'Software & Updates' -> 'Additional Drivers' helpy helper or as described here. Performance will still suck hard, but it should be somewhat less painfull than generic VGA The core components are the same across the various Ubuntu 'spins', the only difference being the default desktop shell and list of pre-installed applications. You can turn xubuntu into ubuntu or kubuntu and vice-versa by installing the relevant desktop packages.

Might be worth trying the driver from the ubuntu repos: From a terminal: sudo nano /etc/apt/sources.list -> uncomment the 'restricted' repos. sudo apt-get update sudo apt-get install fglrx Or do it from 'ubuntu software centre' silly GUI

Nailed it Time to chill out and work on undoing the damage done. That [dead] makes me very sad.

Actually, I was wondering what that was about. Since I swear like a pirate IRL it didn't even occur to me it might be impolite. Might have to update my lexicon

In the FOSS community, that's whats known as a 'hostile fork' While it may be within the rules as written it's disrespectfull, impolite and counterproductive. More often than not the result is exactly what we've seen here: the original author says 'fine then, you deal with it' and leaves. Win x64 is FUBAR, suck it up and move on. I for one would prefer to run just a few mods on x32 than have no mod at all because some prat stomped on the authors toes one too many times. Now, how do we lure Chris back so this lovely piece of work can live on?

Distro? on Debian it's 'apt-get install fglrx-driver' but I don't have an AMD card to test it on. You're not trying to install GPU drivers in a VM are you... that's not gonna work. IMHO Dual boot really is the best way, even if you only use GNU/Linux for KSP it's as simple as reboot - select Linux - play KSP - reboot - select Windows - do other stuff.

I'm going to be lazy and quote wikipedia: "There has not yet been a single widespread Linux virus/malware infection of the type that is common on Microsoft Windows; this is attributable generally to the malware's lack of root access and fast updates to most Linux vulnerabilities." While there are rootkits and trojans out there, they typically target specific, server orientated software such as Apache or OpenSSH. Holes in these are patched swiftly as they power ~70% of the web as we know it. Because users don't tend to run random binaries the way IME they do on Windows and no-one except Chuck Noris runs as root for day to day activities privilege seperation tends to work as intended. *nix was designed to have many, many users on the one system and it's pretty important that a singe users foolishness can't bring down the whole OS. The way system software is installed is also totally different, it's not that it would be hard to write GNU/Linux malware, more that it would be very difficult to hide it *and* trick the superuser into installing it - try embedding a virus into a bit of open source code and see how many distro maintainers include it in the repositories. Creating a fake installer exe for windows with something unpleasant inside is somewhat easier - windows users are used to running downloaded binaries and clicking 'yes' when asked for privilege escalation. Of course the standard precautions still apply, i.e. if you don't know what it is don't execute it. Nor does it stop a malicious site hijacking your browser through some 0-day exploit - but that's the browsers problem and once again can't get into tho OS unless you do something *really really dumb* like running a web browser as root.