Does this mod work under Linux?
Opened this issue · 18 comments
Hello.
This mod was installed as a dependency of KerbalFoundries2 and now all the parts of this mod (landing gears) are just black. Besides it seems to brake another mod (B9 Aerospace Procedural Wings - Fork). The procedural wings are now black as well.
I run KSP 1.8.1 on Linux Mint 19 64 bit
When I run the same under Windows 10 64 bit, all the textures are OK.
Is this mod and all of its dependants supposed to work on Windows only?
KSP.log
In theory, it should run under Linux. I have included the shader compilation targets for OpenGL-Core for both OSX and Linux. However, I have no means to test either of those OS's.
Hello and thanks for your reply.
Can I in any way help with testing? I appended KSP.log if it can be useful. I can also attach some images how it looks in the game
Thanks, will take a look at the log; it should tell me if the shaders didn't load for some reason, or if an incorrect API was requested.
Currently nothing can be done for testing, but I might have something after reviewing the logs.
Hello,
Some update. I finally decided to upgrade KSP to the latest version and now textures are visible.
There were only some problems with KerbalFoundries2, landing gears were remaining black when using TU included with the archive https://github.com/shadowmage45/KerbalFoundries2/releases/download/2.4.8.18/KerbalFoundries-2.4.8.18.zip. I replaced TU with the version shipped by CKAN and now ALG textures are also visible. Thank you for the great work.
The only thing I do not understand: why is the Recoloring Gui available on some Procedural Parts only? Can stock parts be recolored?
Recoloring is only available by the mods that provide patches/textures for them. I provide some for SSTU, but beyond that, pretty much nobody in the mod scene was interested.
SQUAD/Stock doesn't provide any, so there is no information for how to recolor things.
For stock recoloring, you can however use TURD -- https://forum.kerbalspaceprogram.com/index.php?/topic/174188-18x-textures-unlimited-recolour-depot/
This is a patch/texture set by another forum member that I work with regularly, who has so far done an excellent job on allowing for recoloring of stock parts. It is what I use when I want stock recoloring...
I have a feeling that is somehow related to GPU.
I've also got this issue on RX 570 and on laptop gpu (T480s), but I've also got an installation on an older-generation intel GPU which worked (x230, but everything is way too slow).
Ugh, I've found a solution!
Just run the game with -force-glcore42 -force-clamped flags. Then it works. Not sure how that is related (it's amd, not nvidia), but that helped instantly.
Some recap (maybe will help people to find this in the google): if you see black textures under Linux (amdgpu or intel driver) in KSP RO 1.8.1 (specifically, RO engines or RO capsules, for example), just add these flags and it works.
@derlaft I have similar issues playing on linux but worse is that the debug log spam results in the game crashing some times.
Have you tried any other combinations -force-glcoreXY ? My frame rates go way down when using -force-glcore42
Have you tried any other combinations -force-glcoreXY ? My frame rates go way down when using -force-glcore42
Yes, I've tried all the values higher, they don't work. Have not tried any values lower.
Can you upload your log? I could not find anything useful in mine.
Player_partial.log
I've attached a partial from the Player.log which is in ~/.config/unity3d/Squad/Kerbal Space Program
You can see the OpenGL error repeatedly. I did some testing with using only parts that didnt have textures unlimited and the messages go away.
OpenGL Error: Invalid texture unit!
(Filename: ./Runtime/GfxDevice/opengles/DeviceStateGLES.cpp Line: 72)
We did a bunch of debugging over in the KSP-RO discord server, which points to an underlying bug in Unity's logging for causing the crash but its induced by multithreaded logging it would seem. So having TU cause OpenGL to spam the log exacerbates the problem.
Ah sorry NVIDIA GeForce GTX 960
kevin@kevin-desktop:~/.config/unity3d/Squad/Kerbal Space Program$ glxinfo | grep "OpenGL"
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 960/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 440.100
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 440.100
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 440.100
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
@klimburg try this workaround instead of launch options, should work on nvidia:
Update: As of NVIDIA 418.30 you can try the "__GL_IgnoreInvalidateFramebuffer=1" environment variable.
Nah that doesn't seem to work textures still look dark and getting the Invalid texture unit! message in the logs still.
Same problem here, KSP 1.9.1 on a Radeon RX 470. The -force-glcore42 -force-clamped flags work, but they cause some other glitches, e.g. the crawler way when viewed from the VAB looks weird, and I have the feeling it impacts performance.
Just wanted to chime in that I had the same problem (1.8.1, using an RP-1/RO install as described here https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Installation-for-1.8.1) and that using -force-glcore42 -force-clamped worked. This was ONLY a problem on my laptop (with an Mesa Intel® UHD Graphics 620 (KBL GT2)); on a desktop with a similar OS (arch linux with GNOME) and a discrete Nvidia card everything worked fine out of the box.
Can confirm, installing MagPie and TU results in logspam (OpenGL errors) and black parts as in @mitko17's screenshot. On top of this -force-glcore42 -force-clamped doesn't work anymore because current scatterer relies on modern opengl features.
Well, no. Not ready yet to just drop the native client, but I imagine it would work (and also enable TUFX which seems nice to have), and probably open a whole can of other bugs in the process that even fewer people know how to fix. :-/