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:

iLlama, you can already review the crew report, surface samples and EVA reports stored in a pod via the right click menu and decide whether to continue storing, discard or transmit each one. The idea of implementing transfer of this stored material to other pods or dedicated storage components in the same vessel via a mod-right click the same as fuel transfer is a good one though, that would be a nice way of doing it.

The idea of an orbital science facility that can process samples/specimens collected by other ships is interesting but I have to say that the current situation where space stations are largely pointless except as refuelling and Kerbal accommodation facilities is probably more realistic... Real life space stations such as Salyut, Skylab, Mir and the ISS were/are fantastic engineering achievements but scientifically they haven't done much of note that couldn't have been done more easily in unmanned satellites or sounding rockets. The main exception science wise is all the knowledge gained about the effects of long duration space flight on humans, in fact that knowledge together with the development of the technology required to keep humans healthy in space long term has been the main benefit of these things.

You can set up an action group to toggle the doors of the science bay (and goo containers if you've got them). It does make sense for this function to be added as an option to the right click context menu though.

I don't think the game should provide the player with a list of experiment/biome combinations that they haven't done yet (even an incomplete one) as it would be a bit spoilery and not very realistic but what I would like to see is a way to review all the experiment/biome combinations that they have already done. That way the player can get answers to questions like 'did I already collect a tundra soil sample?' or 'was it Mun's East Crater or that other one of the far side that I did that EVA in?' without having to send a suitably equipped ship all the way to biome in question to find out. The list could also include the science value of the last time the particular experiment/biome combination was done giving the player some idea about how much might be gained from any further repeats.

I've been enjoying 0.22 so far but while playing last night it struck me that I'd really like some way to transfer surface samples, EVA reports and the like from one docked ship to another. I'd got to the point in career mode where I'd unlocked docking ports and was excited about the prospect of starting to use the more fuel efficient, elegant and realistic feeling 'lander + command module + service module' (a.k.a. Apollo-like) approach for missions to the Mun and beyond but realised that without a way to transfer the science gathered on the surface from the lander to the command module for return to Kerbin I'd be missing out on some of the science return if I did. Currently if you want maximum science all your landers, or at least their pods, need to be capable of return, re-entry and soft landing on Kerbin which pushes you into using ship and mission designs that just look and feel wrong, at least to me, e.g. Mun landers with parachutes, flimsy lander pods being used for re-entry, etc, etc. One of the reasons that I like KSP so much is that it manages to combine being fun and accessible with enough realism to be engaging and satisfying. Generally speaking the approaches that work well in real life work well in KSP (and vice versa) because much the same underlying principles are at work, and for me that contributes significantly to the immersivity of the game. Here though is an example of the game mechanics (or rather the absence of a particular mechanism) pushing the player away from works best in real life and that does irk me a little. This all relates to the more general issue of the side effects of the perfectly logical science bonus you get for returning samples and specimens to Kerbin instead of just transmitting results. With an incentive to bring lander pods, goo containers and science bays back to the surface of Kerbin it pushes players into hitting the atmosphere with increasingly bulky, lumpy and implausible looking return vehicles instead of the traditional and far more believable command pod + parachute(s). Aesthetics and realism issues aside (which I accept don't matter to everyone, and should take second priority to gameplay considerations) if this becomes standard practice it's going to be even more difficult for Squad to introduce either re-entry heating or more realistic aerodynamics without massive upheavals to game balance, and I think both are still official Planned Features.