DrHotdog

Far be it from me to discourage people from trying Linux but perhaps worth bearing in mind that the Linux screenshots are to some extent cherry picked. The Linux version is WIP too, and is subject to some of the same glitches. In one mission I think I spotted most of the known issues listed in the Linux version Readme.txt file, e.g. Clouds are sometimes glitchy when close Rainbow coloured ground haze Lines of various types appearing where they shouldn't Scatterer atmosphere reverts to Kerbin sized in map mode Sun faintly visible through the Earth (only happened once) Ground can be oddly bright (that's Africa, not Antartica) Flickering and banding of cloud under some conditions (z-fighting?) Also I don't seem to be able to enable city lights through the EVE GUI, and the terrain effects don't seem to showing up much either. Still, I'm happy to put up with these occasional glitches in exchange for the beautiful Scatterer and cloud effects.

Understood, and in any case it's really the EVE Overhaul repo that is missing documentation, not the RVE one. Yep, reinstalled RSS and the very latest RVE and now it's all working (apart from the known issues mentioned in the readme) I've got to say that this looks absolutely beautiful, you're doing great work here!

Ah, worked out where I went wrong! I was confused by the structure of the EVE ZIP archive from the GitHub repo. What I was doing was extracting the /EnvironmentalVisualEnhancements-Overhaul/GameData/EnvironmentalVisualEnhancements/ directory from inside EnvironmentalVisualEnhancements-Overhaul.zip to my GameData directory, but that only contains the shaders, not the DLLs. What I needed to do was open the x86-Release.zip archive that's inside EnvironmentalVisualEnhancements-Overhaul.zip and then extract the /GameData/EnvironmentalVisualEnhancements/ directory from inside that. I have to say that is non-obvious, at least for people that haven't installed EVE Overhaul before, and there's no instructions in the EVE repo. Anyway I can now open the EVE GUI with Alt-E and activate clouds, etc.! Now I just need to fix that RSS config thing.

I seem to be getting the RVE Scatterer effects (more or less, map view shows a Kerbin sized atmosphere inside Earth though) and lens flare but nothing else. Do we need to activate clouds, terrain, etc. via the EVE GUI like the Windows version? Alt-E does nothing under Linux. EDIT: P.S. Any way of getting the lens flare in front of everything except GUI elements? Here it seems to be in front of the Earth but behind my craft.

It seems to be worse than simply not being accounted for in the Build Aid window or Life Support Monitoring, the recyclers on my Duna mission and Mun base don't run unless the vessel they're part of is currently focussed. Each time I switch back to them after a week or two doing other things I find an accumulations of CO2 and waste water and have to keep them focussed for a bit to get the recyclers to turn them (or rather 90% of them) back into O2 and water. Is this a known issue with TAC or have I found a mod incompatibility? Interstellar seems a likely culprit in my case given the widespread changes it makes to the power generation mechanics.

I'm not sure it's a simple as using a compositing window manager or not. I've always run KSP under a compositing window manager (Gnome 3.6 and 3.8) and the only issue I have is with antialiasing. Which specific problems did you have that were solved with the change to IceWM?

Thanks for the suggestion but it made no difference. I have AA and Vsync disabled in KSP and enabled in nvidia-settings (and set to override app settings) but there are still jagged edges everywhere What card, driver version and actual settings are you using?

Hi guys, can someone tell me whether it's possible to get anti-aliasing to work with KSP and the NVIDIA proprietary drivers? I've seen some comments about the Unity engine not playing nicely with the AMD drivers as far as anti-aliasing is concerned but no mention of NVIDIA problems. I have a GT640 with the 331.20 64-bit drivers (installed via RPMFusion on Fedora 19) with a monitor on the DVI port and a TV on HDMI and am running KSP full screen on the monitor. I've tried setting anti-aliasing to max (8x) in KSP itself, tried telling the NVIDIA drivers to override the app settings and enable anti-aliasing via the nvidia-settings GUI, via the nivida-settings command line (e.g. nvidia-settings --assign FSAA=14 --assign FSAAAppControlled=0 --assign FSAAAppEnhanced=0), via exporting environment variables (e.g. export __GL_FSAA_MODE=14) and by setting environment variables at runtime (e.g. LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 __GL_FSAA_MODE=14 __GL_LOG_MAX_ANISO=4 ./KSP.x86_64) but nothing makes any difference, I don't get any anti-aliasing at all. Any suggestions? P.S. Mods, how about a subforum for Linux specific support & bugs? Having a single monster thread for all things Linux makes it hard to find things.

Already suggested: http://forum.kerbalspaceprogram.com/threads/53588-Ability-to-transfer-surface-samples-EVA-reports-etc-between-docked-ships

I've set up my own KSP save cloud sync using Dropbox (any cloud storage provider would do), once you know how to make a symbolic link it's easy. Symbolic links are common in Linux but not often used in Windows, there's a guide on how to use them here. Anyway, this is what I did: On my desktop computer I moved (not copied) my saves folder to somewhere in my Dropbox folder. In the original location of the saves folder I created a symbolic link pointing to its new location in my Dropbox folder. The link enables KSP to still see the saves folder despite it having been moved and now all changes will be automatically synced to my Dropbox account. On my laptop I moved the individual KSP saves (the folders inside the saves folder) to the save location in my Dropbox folder that I created using my desktop computer. Now all my KSP saves from both computers are in Dropbox. Finally I deleted the original save folder and replaced it with a symbolic link pointing to the Dropbox saves folder the same as on my desktop. Now all changes to my save files on either computer will be automatically synced to the other one via Dropbox.

It is a good idea... but it has already been suggested about half a dozen times already...

Yes, but as with the goo cannister the science in the science bay is in the form of samples (it is implied in game that the science bay is a collection of materials science experiments). For it to make sense to transfer the stored science from one module to another in space you do have to assume that they have been designed so that it's possible for a Kerbal in a space suit without specialised equipment to open the container, extract the samples without damaging them (much) and put them into the other container. You can argue that one either way, while having transferable samples is undeniably useful making it possible to do in space would add significantly to the complexity of the science modules so there isn't a compelling reason to assume it would definitely be the case. Personally I don't have a problem with this being made possible but I think it should definitely have to be done via EVA if so and should involve a small science value penalty. With data based science it is obviously different, it makes sense for that to be easily transferable with no loss. With surface samples I think it's reasonable to assume that a bag of Mun rocks or whatever could be chucked through a docking port into another pod if required. EVA reports are part data (hence the 50% transmission rate) and, presumably, part memories of the Kerbal that did the EVA so stored EVA reports should follow the Kerbal if they move from one pod to another.

I like it, at least for science modules that produce data rather than material items (thermometer, barometer, accelerometer, gravitational flux meter). The ability to transfer exposed mystery goo or materials from a science bay directly to another module would make less sense though, it should at least require a Kerbal to go EVA to do it if it's going to be possible at all and perhaps should result in some loss of stored science value to account for the Kerbal having to handle goo in zero-g while wearing bulky space suit gloves instead of doing it in on the ground in a well equipped R&D facility. Your data transfer idea goes nicely with my suggestion about transferring surface samples and EVA reports from one pod to another: http://forum.kerbalspaceprogram.com/threads/53588-Ability-to-transfer-surface-samples-EVA-reports-etc-between-docked-ships

You weren't the first either, Sathurn, there have been several threads discussing this, e.g. http://forum.kerbalspaceprogram.com/threads/53339-Complete-list-of-experiments

This is what I've been doing but the parts that store surface science results (i.e. lander cans, goo units and Science Jr.) are pretty big. Even if you limit yourself to, say, just a Mk1 lander can with two goo units the 'experiment module' still ends up roughly the same size as the Mk1-2 command pod that it's docked to. You do get to be a bit more efficient by not taking all your return trip fuel and engines down to the surface and back, and by ditching the rest of the lander before return, but the resulting re-entry vehicle just doesn't seem right. Imagine the vessel below after decoupling the lander base and service module: