soulsource

As a small sidenote: I could not stop playing with this Linux issue, and it seems that the HLSL->GLSL converter of Unity is to blame. Maybe we should file a bug report there... I've looked at the generated GLSL code using Mesa's shader replacement feature, and the generated code is everything but compiler friendly. Here's an example (one of the shaders that uses dither): https://pastebin.com/KUpVnT2R Unity converts the local compile time constant array into an uninitialized global array, that then is copy-initialized in the shader's main function . Obviously the llvm AMD shader compiler is seeing this write access happening, and decides to make it a real, in-memory array instead of compiling it in as constants. I've made some trivial edits to the generated GLSL code, and that also brought performance up to speed (tested with Mesa's shader replacement feature again - I don't know how to make Unity do the same thing ): https://pastebin.com/yCbXqHa1. The only difference being that the array is const again, and initialized right at declaration instead of copying the single values into it in the main function... So at least we now know what was going on...

So, sorry for the confusion. The pull request is open again, and should now work on shader model 3 as well. https://github.com/LGhassen/Scatterer/pull/52

What I've found up to now is that the Bayer pattern array seems to be placed in private memory, instead of being hardcoded or stored in registers... I think the following snippet compares the same shader, once with the Bayer pattern as an array (old file), and once with it computed with the formula from Wikipedia (new file): https://pastebin.com/GAuSLWPx (think, because I have no experience when it comes to reading assembly). Here's a pull request for your consideration: Edit 3: Please disregard, it's not building for Windows... https://github.com/LGhassen/Scatterer/pull/52 As said, this change improves performance on Linux with AMD hardware a lot, but as it does more computations (instead of using precomputed values), it might decrease performance on other platforms and should therefore be tested before merging (I would actually even consider conditional compilation, in the worst case)... Edit: The merge request requires shader model 4. I don't know if scatterer supports d3d9, but if it does, please tell me, then I'll rewrite it so it does not use any bitwise operators. Edit 2: I just saw that when building for Windows shaders for SM 3 are being built. I'll fix that. Edit 4: See post below.

I might get crazy: By just removing the dither function completely (meaning: just making it return the input value) performance drastically increased on Linux. Like, from 35 to 45 fps on my machine... Edit: It has something to do with the size of the bayerPattern. Edit 2: That gives me an idea. The matrix can be replaced with a formula (https://en.wikipedia.org/wiki/Ordered_dithering). I'll try that tomorrow, and if it indeed improves performance, there will soon be a pull request.

Hmmm, it seems performance on Linux went down the drain with The culprit seems to be the added dithering in atmospherePostProcessing32bitViewSpaceDepth.shader. By undoing --- a/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader +++ b/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader @@ -306,7 +306,7 @@ Pass { // inscatter*=eclipseShadow; //#endif - return float4(hdr(inscatter)*_global_alpha*returnPixel, 1); + return float4(dither(hdr(inscatter)*_global_alpha, screenPos)*returnPixel, 1); I got performance back up to acceptable levels, also with shaders from 0.0336. I'll investigate this further, because the dither function itself looks reasonably benign, so there has to be something crazy going on in either Unity's HLSL->GLSL converter, or in the AMD shader compiler... (I originally thought that we get register spilling, but meanwhile I'm rather certain that we can rule that out...)

I'm seeing the same issue. No nullrefs, but a huge FPS impact of scatterer's post processing. Disabling post processing in the scatterer menu immediately yields good FPS again... The issue does not exist with 0.0331b. Edit: It's certainly caused by the shaders, as running 0.0331b with the shaders file from 0.0336 also yields significantly lowered fps on Linux, while running 0.0336 with the shaders file from 0.0331b does not yield the fps drop. (Might also be hardware specific - I have an AMD card with radeonsi drivers). Edit 2: I'll try to get Unity set up on my machine. If I manage to get it working (last time I tried it was a bit a PITA on Linux), I'll try to do a git bisect this weekend, to find the offending commit.

It seems to work if you unplug your controller while starting KSP (and in the settings menu), but re-connect it once the game is loaded. I need to test this further. Haven't played any KSP in quite some time because I made the mistake of buying Rimworld...

It's a file in the FAR source code. Details are somewhere in the last few pages of this thread.

Phew, that was some time ago... Let's see if I remember correctly... Somewhere in the last few pages of this thread (sorry, I don't have the link any more) there's a link to a forked github repo with a version of FAR for 1.4.1. I checked out that repo, made the changes to the compatibility checker file, recompiled it, and installed that version to my GameData folder. I think I also copied over the shaders package and icons from the last official release.

Thanks. I think I got it working. My dll files were OK, but I guess I somehow managed to get old config files into my FAR installation, missing the config for the Mk1 pod.

Hmmm, I've tried recompiling, and got it to kinda work, however I still have the issue that drag is nearly zero when re-entering the atmosphere... Any advice? Edit: Here's the log, if anyone is interested: https://drive.google.com/file/d/1w6HWPIZ8tppoJYAK9BXKB_J-bWJltALa/view?usp=sharing While there are no lines directly related to the issue, the Flight Data GUI spits out this: OverflowException: Number overflow. at System.Decimal.op_Explicit (Decimal value) [0x00000] in <filename unknown>:0 at StringLeakTest.StringBuilderExtensions.Concat (System.Text.StringBuilder string_builder, Single float_val, UInt32 decimal_places, UInt32 pad_amount, Char pad_char) [0x00000] in <filename unknown>:0 at StringLeakTest.StringBuilderExtensions.Concat (System.Text.StringBuilder string_builder, Single float_val, UInt32 decimal_places) [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightDataGUI.CreateDataString () [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightDataGUI.DataDisplay () [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FlightDataWindow (Int32 windowId) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1)

Effective exhaust velocity, measured in meters per second. NASA was/is using international units anyhow.

It's always 9.81 m/s² in this formula, as it's a conversion factor to convert specific impulse measured in seconds into specific impulse measured in m/s. In my humble opinion it does not make any sense to measure specific impulse in seconds when talking about spaceflight, but people do it for historical reasons anyway...

I don't know if that still applies: https://www.reddit.com/r/KerbalSpaceProgram/comments/4h4hwv/my_slow_startup_load_fix/

To be honest, that does not really sound like it's a KSP issue, more like your filesystem might be corrupted, a hardware fault, or some malware messing around with your system (not that I'm saying it's one of these, but keep the possibility in mind, and backup important data). To fix a Steam game install all you have to do is to right click the application in your library, go to properties, local files, and there should be a button "verify integrity of game files". By pressing this button, the game's install folder is checked for errors, and if files are found to be corrupt, they get re-installed.

LinuxGuruGamer picked up the Advanced Fly-By-Wire mod. Maybe this can help, given it was originally written to reduce input lag?

We have the same issue on Linux, it has been discussed in length. The solution that worked for me was to use Advanced Fly-By-Wire. I've also posted an updated Advanced Fly-By-Wire dll for Linux in that other thread, and steps on how to compile the plugin, which you could try for Mac. I don't know if that plugin supports Mac OS though.

You'll need SDL2 if you plan on using Advanced Fly-By-Wire (that's all explained on the Advanced Fly-By-Wire github page, together with the Advanced Fly-By-Wire install instructions). If however you think you can get your joystick working without Advanced Fly-By-Wire (I could only get the keys working, not the axes), you do not need to manually install SDL2, as Unity is statically linked against it. This static linkage is also what might cause my Advanced-Fly-By-Wire build (see my linked post) cause KSP to lock up, but there is an environment variable workaround (again, see my posting in the other thread). Oh, and regarding CKAN: I have no idea how to get it working properly. It more often bugged out than it actually worked for me, so I stopped using it a long time ago.

There has been a question about this already, and yep, in 1.4 joysticks and gamepads do not work on Linux. I did manage to get them to work with Advanced Fly-By Wire though, and linuxgurugamer seems to have picked up maintaining that mod. Anyhow, I've meanwhile uploaded a "working" Advanced Fly-By-Wire dll at the other question:

I prefer Career, although I think it could be balanced a bit better, to make it more challenging. For instance in order to get to other planets, one needs to unlock rather potent antennae (or send a crewed vessel without any radio connection - something I don't like for roleplaying reasons), meaning one has to progress quite far in the tech tree with Mun and Minmus only, leaving only a few nodes to be unlocked with science from other planets. Money is another issue. Either you set your game difficulty to have lots of money available, then it isn't really a constraint and one could just play science mode instead, or the game starts to feel grindy almost immediately. Anyhow, I haven't yet found a setting where contract payments felt "right", meaning that one has to take care when building a new craft to stay on the cheap side, and still not being forced to do an insane amount of repetitive contracts to upgrade the buildings.

This should go to the tech-support forum, imho. If you bought the game through the KSP store, you can find downloads for the various language packs right at the same spot where you downloaded the game. I don't know how to change language for the Steam version though.

Also: dxdiag output and KSP log file.

I've been messing with the broken Joystick/Gamepad support of 1.4.x on Linux again. After I installed the latest round of updates for my distribution, Advanced Fly-By-Wire broke again for me, as the version of libSDL2 was updated from 2.0.4 to 2.0.8. Anyhow, I spent the last three hours finding out why that causes breakage, and finally found a solution (Edit 5 of linked post). Now that I finally can play KSP with my gamepad again, I'm too tired to do so. Well, tomorrow is another day .

Try using Advanced-Fly-By-Wire. I detailed how to get it running with 1.4 in the other question about missing Joystick/Gamepad support on Linux. Beware though, that my build of the mod is only for Linux. For Windows you'll need to compile it yourself, using the appropriate project file.

There's also another reason for negative reviews: C) people complaining about bugs in the latest release that weren't there in the previous one That's why I'd suggest to get KSP from the KSP store instead of Steam. If one isn't careful, Steam might update the game without warning, and one might end up with a version where something important is broken without an easy way to downgrade. If you use the store version, you can just update once you know it's safe to do so ;-)