[Linux] Not starting

[8Kuula]

I have tried reinstalling and deleting whole ~/.local/share/Almost Human directory, but for some reason LoG just do not start.

$ steam -applaunch 207170
Running Steam on ubuntu 14.04 64-bit
STEAM_RUNTIME is enabled automatically

That was useless.

How I can start it so that I can see command line output? if there is any.
Or how to fix this?

OS: Ubuntu 14.04 64bit
nvidia GTX 980 (346.35)

[Dr.Disaster]

Oprindeligt skrevet af alx242:

Even if they hired someone external resources to create the linux version we are plenty of people that have supported their product and that should be enough to make some movement on their behalf.

That's exactly, what AH did: they hired an external guy to do the port. Now the bad part is that this external dude either can't or won't support his work anymore

Oprindeligt skrevet af alx242:

Please Almost Human, hire some linux person to get on top of this. Perhaps you could even squeeze out Grimrock 2 for Linux as well :) I seriously want to finish this game on my Linux box :)

They first need the source code of this external dude that can't/won't help anymore before they could hire another guy to patch anything. Otherwise they need to hire a new guy to do the whole port again

[fableman]

Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).

[[LINUX]Wolfyrion]

seriously no fix ? :o?

[Dr.Disaster]

Oprindeligt skrevet af fableman:

Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).

Well .. feel free to apply for the job then mr. gamedev!
Last time i checked back with AH they were still looking for a linux guy capable of doing it.

[fableman]

Oprindeligt skrevet af Dr.Disaster:

Oprindeligt skrevet af fableman:

Seriously, how hard can it be to debug the game and solve the segmentation fault issue? It always comes down to a few coffees, a few hours of debugging, reading a few forums/whitepapers and the problem is solved and after that you can safely resubmit the game to steam. I reckon they are just done with linux port due to lack of motivation to do any extra work on it. And please, don't BS me with this "they don't have the source code from the porter" crap. They always do (gamedev myself).

Well .. feel free to apply for the job then mr. gamedev!
Last time i checked back with AH they were still looking for a linux guy capable of doing it.

Thanks, but I'm already in a pretty decent spot at this moment. Tbh, I'm merely here to express my feelings about the whole situation, nothing else.

[BigDaddyDelta]

Oprindeligt skrevet af directhex:

Oprindeligt skrevet af BigDaddyDelta:

I've created this small workaround for this game, So far it has only been tested on my system with a GTX 960 and drivers 349.16. Link: https://drive.google.com/open?id=0Bw5Xv02Yq2HrUlNSV01rRHpaNzQ&authuser=0

If you test it please let me know if it works or not.

Screenshot: http://s1.postimg.org/8sixagd8t/grimrock.jpg


UPDATE: Workaround still works for me with the new drivers 352.21

So your workaround is just to bundle a chunk of the NVIDIA driver with the game, such that it gets preferentially used?

Unfortunately yes, I'm not a programmer and I understand this workaround may break at any time as newer Nvidia drivers come out.

At least for the time being it lets me play the game without having to lock myself to older drivers, Doesn't leave out the fact that I'm still hoping for a proper fix from the devs.

Like I said, I can only test this on a GTX 960, if any 970+ owners can test this too I can forward more information to the dev.

[Faugn]

OK, so this workaround (using the old drivers) does not work for me (I'm on Arch Linux, NVIDIA driver: version 352.21). I took a closer look at the issue: it seems to be a buffer overflow when handling the GL extensions string (more than 8K)... That's some sloppy code... Anyway, I've made a small library override, that "fix" the extensions string when glGetString(GL_EXTENSIONS) is called (by stripping the end to limit to 8K max). Not pretty, but it works: the game starts, and so far, I'm not seeing any graphical issue (all graphics set to max).

Here is a script to patch the Steam version:

#!/bin/sh

set -x

mv Grimrock.bin.x86 executable.x86 &&
printf '#!/bin/sh\nexec env LD_PRELOAD=./lib/glfix.so ./executable.x86 "$@"\n' >Grimrock.bin.x86 &&
chmod +x Grimrock.bin.x86 &&
gcc -m32 -D_GNU_SOURCE -shared -fPIC -lGL -ldl -x c - -o ./lib/glfix.so <<\EOF

#include <stdio.h>
#include <string.h>
#include <dlfcn.h>
#include <stdlib.h>
#include <assert.h>

#include <GL/gl.h>

const GLubyte *(* __real_glGetString)(GLenum name);

static GLubyte _gl_extensions[8 * 1024];

static __attribute__((constructor)) void _init(void)
{
    __real_glGetString = dlsym(RTLD_NEXT, "glGetString");
    assert(NULL != __real_glGetString);
}

const GLubyte *glGetString(GLenum name)
{
    const GLubyte *res;

    res = __real_glGetString(name);

    if (GL_EXTENSIONS == name && NULL != res)
    {
        size_t len = strlen(res);

        if (len >= sizeof (_gl_extensions))
        {
            GLubyte *end;

            strncpy(_gl_extensions, res, sizeof (_gl_extensions));
            _gl_extensions[sizeof (_gl_extensions) - 1] = '\0';
            end = strrchr(_gl_extensions, ' ');
            assert(NULL != end);
            len = end - &_gl_extensions[0];
            assert(len < sizeof (_gl_extensions));
            *end = '\0';
            fprintf(stderr, "glGetString(GL_EXTENSIONS): stripping \"%s\" [%u]\n", res + len, strlen(res + len));
            res = _gl_extensions;
            fprintf(stderr, "glGetString(GL_EXTENSIONS): returning \"%s\" [%u]\n", res, strlen(res));
        }
    }


    return res;
}

EOF

It needs to be run from the Legend of Grimrock installation directory (default: ~/.local/share/Steam/SteamApps/common/Legend of Grimrock).

And for the record, I agree with fableman, how hard can it be to fix this issue from AH side?

[Dr.Disaster]

As hard as it can be to find a reliable linux dev ..

[Petri]

Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.

[von]

Oprindeligt skrevet af petrih:

Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.

Works for me, thank you.
intel core i5-3570, nvidia gtx970 (driver ver. 352.21), arch linux

[Faugn]

Oprindeligt skrevet af petrih:

Apologies for the long delay!

We have just pushed a new Linux beta to Steam that should fix this issue. Could you please test it by opting into the "linux_beta" branch (in Library -> Legend of Grimrock -> Properties -> Betas)?

I hope this finally solves this embarrassingly long standing issue.

Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.

[Petri]

Oprindeligt skrevet af Faugn:

Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.

The issue was caused by a buffer overflow bug, like you described earlier. I guess the real issue is that we are a very tiny team (just 1 programmer) with practically no Linux experience and trying to juggle with multiple projects and platforms at the same time (win, mac, linux, ios). Again apologies for taking so long to fix this.

[Faugn]

Oprindeligt skrevet af petrih:

Oprindeligt skrevet af Faugn:

Works fine here too (NVIDIA GTX960, driver 352.21, Arch Linux). Can you comment on what was the underlying issue? I'm curious.

The issue was caused by a buffer overflow bug, like you described earlier. I guess the real issue is that we are a very tiny team (just 1 programmer) with practically no Linux experience and trying to juggle with multiple projects and platforms at the same time (win, mac, linux, ios). Again apologies for taking so long to fix this.

Better late than never! Thanks for taking the time to reply. A great Linux tool for finding such memory related issues is Valgrind (it's what I used in combination with strace and ltrace). Cheers.

[Squiddy]

Fantastic! Tested it working! Thank you so much for your effort and not leaving us in the cold, it's very much appreciated.

[Nabushi]

Thanks for this