Technologicat

@arctangent: Thank you! I can confirm that the DLL libstdc++.so.6.0.22 from libstdc++6_6.3.0-18_amd64.deb fixes the issue perfectly on Linux Mint 17.2. This version of Mint is otherwise problematic: the default libstdc++.so.6 is too old, whereas the one from the ubuntu-toolchain-r PPA (as suggested on StackOverflow as a solution to a similar problem) is too new (libstdc++.so.6.0.23, newer ABI) for KSP 1.3.0. In case anyone else runs into this problem (and upgrading Mint is not an option for them), instructions: Open your KSP_linux directory in the file manager For 64-bit KSP, download the deb package, for the amd64 architecture, from the Debian site. Link posted by arctangent. Open the downloaded deb package with Archive Manager In Archive Manager, inside the deb package navigate to /usr/lib/x86_64-linux-gnu/ Extract libstdc++.so.6.0.22 into your KSP_linux directory Open a terminal in your KSP_linux directory In the terminal, create the symlink, since KSP will look for "libstdc++.so.6": ln -s libstdc++.so.6.0.22 libstdc++.so.6 It is possible to just rename the file to libstdc++.so.6, but this has the advantage of preserving the information about the ABI version in the filename. Create a startup script (run.sh) that tells Linux (technically, the dynamic linker) to prefer this libstdc++.so.6 over the system one when starting KSP: #!/bin/bash LD_LIBRARY_PATH=. ./KSP.x86_64 Basically, this first tries loading any DLLs (.so) from the current directory before defaulting to the system paths. Set the startup script as executable: chmod +x run.sh Then, to start KSP, open the KSP_linux directory in the terminal, and execute ./run.sh Final note: a startup script can be useful in other non-standard configurations. For example, my run.sh says #!/bin/bash LD_LIBRARY_PATH=. __GL_THREADED_OPTIMIZATIONS=0 primusrun ./KSP.x86_64 which runs the game through primusrun (to run the graphics on the NVIDIA GPU). I'm not sure if __GL_THREADED_OPTIMIZATIONS=0 is needed any more, but I've left it in just in case

@Yemo, @Angel-125: Any interest in a small MM patch adding Snacks! support to the SETI greenhouse, that I put together for my own campaign? The motivation is that KPBS already adds planetary greenhouses, but right now there is no Snacks!-compatible orbital greenhouse to include on the mothership for those long interplanetary flights (or on a space station). I'm just getting into playing with a life support mod myself, and ended up choosing Snacks! for its simplicity and stockalike feel. I was thinking that in Snacks!, the greenhouse could act as a soil recycler, like the stock hitchhiker can does. To compensate for greenhouse's mass and the zero crew capacity - indeed, its dedicated role - it would be a higher-output recycler. Out of the box, the hitchhiker can is calibrated to provide enough recycling capacity for 4 kerbals, so, for example, the small greenhouse could be similarly calibrated for 6 and the big one for 8. The patch was rather trivial to make, based on the working config examples provided with Snacks!. Beside modifying the capacities, I only patched the descriptions to match the behaviour. The difficult part, of course, is to get the gameplay balancing right. So far I've just tested that the patch poked the right things to indeed make the SETI greenhouse work as a recycler in Snacks!. I haven't yet thought about the numbers. The calibration of the stock hitchhiker can is at 100% recycler efficiency, 1 snack per meal, 1 meal per day. In Snacks!, all these values are set by the player, in the game difficulty options. The recycler efficiency, in particular, can be anything from 10% to 100%. The KSPedia screenshots in the OP of the Snacks! Continued thread imply that the official recommendations are 1 snack per meal, 3 meals per day, 40% efficiency (correct me Angel if I'm wrong ). At these settings, one hitchhiker can is sufficient to recycle enough food for 40% * 4 * (1/3) = 0.53 kerbals. Given the dedicated role of the greenhouse, maybe the small one could recycle enough food for 2 (maybe 3?) kerbals and the big one for 4 (maybe 6), at the officially recommended settings? This would give theoretical capacities of 16 (24) and 32 (48), respectively - but on the other hand, these values are insane when run at or near 100% efficiency, and less than 3 meals per day. Comments?

Linux user here. I tried TRR in KSP 1.3.0, but with reflections enabled, the EVA visor shows as a pink blob, which probably indicates that the shader didn't load. Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, driver version 352.79 running OpenGL 4.5. For comparison, the version of TR updated by Ger_space has working EVA visor reflections in Linux. It seems TR and TRR use different shaders for this - TR has tr_reflective_emissive_alpha.ksp (lowercase, 58.3kB), DirectX.bundle and OpenGL.bundle, whereas TRR has TR_Reflective_Emissive_Alpha.ksp (CamelCase, 96.0kB) and TRVisor.ksp. I've switched to TR for now (which may also be more appropriate for the time being, considering existing suit packs), but I can drop TRR back in and provide a log if you want to investigate this.

@Ger_space: It does! Thank you! Confirmed working: Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, drivers 352.79 running OpenGL 4.5. I'm still getting these messages in Player.log: WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - Pass 'FORWARD' has no vertex shader WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - Pass 'FORWARD' has no vertex shader WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - All passes removed ...but the visor reflection on the EVA suit works. If you want to investigate, I can make a clean install with TR only (my current install has dozens of mods), and then dropbox a full log. Second @Kerbart's suggestion about appIcon.dds. Not a major issue if you happen to have an old install to pull it from, but would be more convenient if it was included in the download

@MOARdV: another Linux user here - I'm having the same pink blob issue. Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, driver version 352.79 running OpenGL 4.5. I'm getting the exact same shader error messages in Player.log as @martinmike2 already reported.

@kBob: Thanks! I have seen that, but thought it might be out of date since the wiki still talks about migration problems and the warning has been there for a long time. Checking the history of the key bindings page, though, says that it's last been updated on 19 May 2016, so it's probably fine. In fact, looking at this diff, which lists the changes to that page between KSP 1.0.5 and 1.1.0, it seems the only changes in 1.1.0 are the addition of '/' to stop timewarp (unfortunately, useful only on keyboard layouts such as EN-US that need no modifiers for '/'), and the change of the modifier key from LAlt to RShift on Linux, which is indeed very nice since many window managers on Linux tend to reserve LAlt for other purposes. I didn't actually notice the latter - I'm playing on Linux and I think I had to remap Mod in settings.cfg with the help of this. In Linux KSP 1.0.4, Mod was RShift, while 1.0.5 used LAlt, and I could have sworn that when I installed KSP 1.1.2 with a default settings.cfg, the default modifier key was LAlt. Would need to do a clean decompress to check, though. In case anyone is wondering, 'Y' is indeed unused. Problem solved. Now to hope there won't be many more key conflicts

Here I was thinking the Kraken had compressed my space probe into a space tuna can, but it turns out I had set a switchable fuel tank as the root part and this update fixed it - in flight. Thanks!

@Jimbodiah: The versions modified by RealGecko and Fwiffo (see download links above) work with 1.1.2, with a minor issue: at night, the floor of a fully upgraded (level 3) VAB appears reddish. This mod is very convenient for fine-tuning lighting on new spacecraft designs - I agree I would miss it if wasn't working

Also, as @RKain101 has already pointed out, also the KER flight computers (Kerbal Engineering System (EngineerChip) and ER-7500 Computer Flight Unit (Engineer7500)) are detected as science experiments. To filter out these, we can use !MODULE[FlightEngineerModule] so that the filter becomes: @PART[*]:HAS[#category[Science],!MODULE[ModuleScienceLab],!MODULE[ModuleResourceScanner],!MODULE[ModuleOrbitalSurveyor],!MODULE[ModuleDataTransmitter],!MODULE[ModuleRTAntenna],!MODULE[FlightEngineerModule]]:FINAL I second the idea of removing the blurb or at least making it much shorter. Just "Returns full science with one trip." or something? Opinions? @maculator?

@Galenmacil, @Honeybadga, @lttito: I'm getting hit by this too - in surface mode, the speed unit doesn't change when using Speed Unit Changer. The common thing is that I also have FAR, and indeed from the FAR menu the displayed speed unit can be changed. Maybe a conflict? @Iamsodarncool: other mods installed? Do you have FAR?

Has anything changed in the keybindings of 1.1.x, or is this still current? I think it's still current? (Trying to find a key on the keyboard that is unused by the stock game, in order to de-conflict some keybindings for mods; the Pilot Assistant and Improved Chase Camera toggle keys are both mapped to Tab by default. By the currently posted version of the keymap, it should work if I map one of them to 'Y'...)

@N1njawarrior: Thanks for the hint! I just want to add that FAR users may want to check that also the FAR flight assistance toggles are off before trying to enable MAF. Took a while before I remembered FAR itself has those buttons Concerning compatibility with various autopilot mods, it seems MAF can coexist with Pilot Assistant (when both are not applying control simultaneously). This is cool - more tools for different purposes. @tetryds: There is one conceivable use case where having MAF and KSP Advanced Fly-by-wire installed simultaneously would be useful: if one sometimes flies with a joystick, but sometimes with the mouse (such as on a laptop, with the joystick at home). Maybe this user group is rather marginal, though? Concerning testing with different craft, there seem to be some stock craft (useful for quick testing of mods in sandbox ) that may present problems at least in FAR. The Albatross flips out of control easily when attempting a hard turn (which probably shouldn't be done given the nature of the plane). The Gull it seems to handle rather well in cruise mode, but in normal mode this plane seems to experience a roll oscillation. Finally, great mod! MAF feels like a nice companion for FAR when using mouse/keyboard control.

A nice simple mod, thanks for the work. Just the functionality I need for starting a new career game Quick bug report: if RemoteTech is installed, the Science - Full reward! description gets added also to RemoteTech antennas, although they have no science experiments. To fix this, add !MODULE[ModuleRTAntenna] to the filter in the .cfg so that it reads @PART[*]:HAS[#category[Science],!MODULE[ModuleScienceLab],!MODULE[ModuleResourceScanner],!MODULE[ModuleOrbitalSurveyor],!MODULE[ModuleDataTransmitter],!MODULE[ModuleRTAntenna]]:FINAL

Yeah, a pp shader sounds like a likely culprit for things like this. Tested - this setting fixed the black IVA. Thanks!

Thanks! Do tell me if you need any logs or help with testing. This was a nice mod in 1.0.5 - nice to see it's being maintained!

Hi, A quick bug report: in G-Effects 0.4.0-rc2, the IVA appears completely black. Only this mod, KSP 1.1.2, Linux 64-bit (and hence OpenGL). Reproducible by starting a new sandbox game, launching one of the stock craft (an AeroEquus will do fine) with Jeb inside, and pressing C while still on the launchpad (before starting the first stage). (Then, for further testing, no need to start a new game - leaving the craft on the launchpad, loading the save, switching to the craft (by clicking its icon in the space center view and selecting "Fly") and pressing C reproduces the issue. Loading the same save without this mod installed, the IVA works as expected.)

Cool. Yeah, it seems a lot of stuff was moved to different modules or the API slightly changed in the 1.1 update, some of it having to do with the move to Unity 5.

Thanks for the new release! I was already beginning to think this was abandoned, seeing that the last release before the new one was for KSP 0.23.5 (though it did work just fine up to KSP 1.0.5). Glad to see the mod officially back! Cars simply need it to feel right. One request: in case you didn't completely discard the old UI code, would it be possible to have the option of using either stock or Blizzy's toolbar, as many mods have? Blizzy's is very convenient for heavily modded installs, since the buttons take up slightly less space, can be reorganized, and the toolbar can have several rows. The stock toolbar tends to fill up pretty quickly - at least at default UI size and if you want to have KER (or VOID) HUD displays at the top of the screen, too. For minimally modded installs stock is better, as it's one less dependency to worry about.

Ok. In any case, it seems this is specific to the stock toolbar - with Blizzy's toolbar it doesn't seem to occur. (I have SM configured to use that and have never seen a duplicate button.) Probably completely different initialization procedure, though Glad that you're back. Yeah, API changes can be a pain. Good luck with the upgrade!

Nice! Glad that you're back. Temporary download removed.

Dunno if this is still relevant, but about the duplicate stock toolbar button bug, I think stupid_chris posted something relevant in the thread for KSP 1.1. (See that post and a few posts back.) EDIT: ...unless you already read about it, didn't notice you posting in the thread when I posted this

Yeah, I'm not suggesting forking the mod - like others, I'd just like a temporary download location to be available while we wait for the original author to return. Posted on Dropbox: [deleted, see new official download by tg626] It's the exact original zip, with only the filename changed to use only underscores and to credit the author. I imagine anyone Googling for "docking sounds tg626" will be pointed to this thread. For those that care about such things, md5sum -b is 6e6a9ec033f6a2cd62ca7716575fd09a, and sha1sum -b is 87f0e78208c51680f699febe459511cb3691855e. @tg626: drop me a PM, or post about it in this thread, and I'll remove the download. I've set up notifications so that I'll get an email alert even if I'm not active on the forums at that time.

Mm, that is a logical choice. I suppose my main concerns here are: It's been "just" three months since tg626's last post in this thread - should we keep waiting for a short while more to see if tg626 reacts (now that we have posted about the unavailability of the download), or just go ahead with an upload? How to upload the mod in a manner such that tg626 can take over the administration of the download page when/if he returns? Or so that someone else can take over? Some temporary location wouldn't be a problem (could be removed once an official download is available again), but on SpaceDock, there will likely be future confusion between a "DockingSoundsTempRedistribution" and a later official "DockingSounds", if both are available at some point. The URL of the future official version (if any) does not exist at the point of time when the temporary distribution is made, so the .version file cannot be made to automatically track official updates. I suppose this is possible to work around - once an official version becomes available again - by updating the temporary redistribution at that point with a dummy release that just changes the version file to point users to the official download, but that requires maintenance. My gaming patterns are too erratic to guarantee that I'll be around to update the temporary distribution possibly much later.

The license is CC BY-SA 4.0, so in case @tg626 goes missing, technically anyone who has a copy (and a place to upload it) is allowed to post it, as long as they credit the original author. I have archived a copy of the 1.2 download, but don't exactly have a place to upload it (other than a github account). What is the preferred way to act in this situation? I'm also hoping that pinging the original author in this thread may bring the situation into his attention

Congrats for the release! Minor issue detected: the download URL in ConnectedLivingSpace.version points to KerbalStuff, although the hosting has been moved to the new SpaceDock. Maybe "DOWNLOAD":"http://spacedock.info/mod/190/Connected%20Living%20Space", ?