It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
ssokolow: MojoSetup supports formats other than Zip which may not have extractors as forgiving so, given that makeself has no tool for unpacking its own archives without executing them, I decided to write one.

https://github.com/ssokolow/makeself_safeextract
avatar
shmerl: Thanks, I tested your tool - it works nicely for Don't Starve.

avatar
king_mosiah: Nope, boring ole ext4.
avatar
shmerl: You can try stracing the game and see what is going on.
I got the game to run by executing start.sh in Nemo (lack of sleep stopped me from thinking of it sooner). It still refuses to launch from the terminal though, strange, but as long as it works...
Post edited August 12, 2015 by king_mosiah
avatar
shmerl: Thanks, I tested your tool - it works nicely for Don't Starve.

You can try stracing the game and see what is going on.
avatar
king_mosiah: I got the game to run by executing start.sh in Nemo (lack of sleep stopped me from thinking of it sooner). It still refuses to launch from the terminal though, strange, but as long as it works...
What, exactly, are you typing to run it? Usually, when that (or the reverse) happens, it's because of a mismatch in chdir() usage.

(Non-GOG Linux releases often have that problem in the form of "Won't run unless you explicitly cd into the directory before running the launch script" because the developers assumed Windows-style "parent directory is default $PWD" behaviour rather than UNIX-style "$HOME is default $PWD" behaviour.)
Post edited August 12, 2015 by ssokolow
avatar
king_mosiah: I got the game to run by executing start.sh in Nemo (lack of sleep stopped me from thinking of it sooner). It still refuses to launch from the terminal though, strange, but as long as it works...
avatar
ssokolow: What, exactly, are you typing to run it? Usually, when that (or the reverse) happens, it's because of a mismatch in chdir() usage.

(Non-GOG Linux releases often have that problem in the form of "Won't run unless you explicitly cd into the directory before running the launch script" because the developers assumed Windows-style "parent directory is default $PWD" behaviour rather than UNIX-style "$HOME is default $PWD" behaviour.)
I tried ./start.sh in the games directory and dragging the start.sh to an open terminal window. It gave me the same error either way.
Post edited August 12, 2015 by king_mosiah
avatar
ssokolow: What, exactly, are you typing to run it? Usually, when that (or the reverse) happens, it's because of a mismatch in chdir() usage.

(Non-GOG Linux releases often have that problem in the form of "Won't run unless you explicitly cd into the directory before running the launch script" because the developers assumed Windows-style "parent directory is default $PWD" behaviour rather than UNIX-style "$HOME is default $PWD" behaviour.)
avatar
king_mosiah: I tried ./start.sh in the games directory and dragging the start.sh to an open terminal window. It gave me the same error either way.
Hmm. What's the error message? I might recognize it.
avatar
king_mosiah: I tried ./start.sh in the games directory and dragging the start.sh to an open terminal window. It gave me the same error either way.
avatar
ssokolow: Hmm. What's the error message? I might recognize it.
Here it is "nohup: redirecting stderr to stdout"

It seems to be stuck in a loop or something, it never crashes but the game never launches... Unless I execute it in the file manager.
Post edited August 12, 2015 by king_mosiah
avatar
ssokolow: Hmm. What's the error message? I might recognize it.
avatar
king_mosiah: Here it is "nohup: redirecting stderr to stdout"

It seems to be stuck in a loop or something, it never crashes but the game never launches... Unless I execute it in the file manager.
Could be an environment difference. Try writing such script: env.sh

#!/bin/bash
env > env.$RANDOM

And run it first from the terminal and then from Nemo. Compare two generated files and spot any suspicious differences.
Post edited August 12, 2015 by shmerl
avatar
king_mosiah: Here it is "nohup: redirecting stderr to stdout"

It seems to be stuck in a loop or something, it never crashes but the game never launches... Unless I execute it in the file manager.
avatar
shmerl: Could be an environment difference. Try writing such script: env.sh

#!/bin/bash
env > env.$RANDOM

And run it first from the terminal and then from Nemo. Compare two generated files and spot any suspicious differences.
done
Post edited August 12, 2015 by king_mosiah
Better don't post all stuff like that as is - it can have private info :)

Anyway, I don't see anything super strange there. Try setting PATH in the terminal to the same value as in Nemo before running the game (export PATH=...).

Also DISPLAY value is different, but that should be OK I think. Try setting it to the same as in Nemo too just for a test.

If that won't help, try eliminating all extra variables in the terminal (using unset command), add all missing ones, and then set all the different ones to the same values (using export). Do that one by one to narrow down what is causing the issue.

To make sure it's a working approach, try first setting exactly everything to the same as in Nemo in the terminal and run the game. If it works, use the elimination approach above.
Post edited August 12, 2015 by shmerl
avatar
shmerl: Better don't post all stuff like that as is - it can have private info :)

Anyway, I don't see anything super strange there. Try setting PATH in the terminal to the same value as in Nemo before running the game (export PATH=...).

Also DISPLAY value is different, but that should be OK I think. Try setting it to the same as in Nemo too just for a test.

If that won't help, try eliminating all extra variables in the terminal (using unset command), add all missing ones, and then set all the different ones to the same values (using export). Do that one by one to narrow down what is causing the issue.

To make sure it's a working approach, try first setting exactly everything to the same as in Nemo in the terminal and run the game. If it works, use the elimination approach above.
Setting the path did the trick and I'll just delete my prior post.
Post edited August 12, 2015 by king_mosiah
avatar
king_mosiah: Setting the path did the trick and I'll just delete my prior post.
Good. I suppose it depends on how your display manager sources (or not) your environment files (/etc/profile, $HOME/.profile, $HOME/.xsessionrc and the rest). It can differ from how it works inside the shell. I currently switched to KDE Plasma 5 on Debian testing, which uses sddm instead of kdm, and that stuff became messed up because sddm doesn't source /etc/profile and $HOME/.profile unlike kdm which did.

No idea what GOG start scripts or the game can use in /sbin and /usr/sbin directories, but it's better to have them in the PATH. Approach to exclude them is really obsolete. You can research it more to figure out what is being called from there.
Post edited August 12, 2015 by shmerl
Not reading everything here, but I just want to mention that using start.sh never worked for me at all. I can run most of the games just fine directly using the binaries in game folder. For some I had to install some libs, but that is possible to troubleshoot.
Looks like Terraria has landed!
Post edited August 13, 2015 by king_mosiah
avatar
Neikius: Not reading everything here, but I just want to mention that using start.sh never worked for me at all. I can run most of the games just fine directly using the binaries in game folder. For some I had to install some libs, but that is possible to troubleshoot.
Posting your specs and distro might help :-)

In any case, do notice that some games come packed with their required libraries and the start.sh tells the executable that these exist without requiring you to install anything. In my case the GOG scripts work fine for me (Linux Mint 17).

My only complaint is that they could include more libraries in some games, instead of just listing them on the game's page, this would give a better out of the box experience.
Post edited August 13, 2015 by Ganni1987
avatar
Ganni1987: My only complaint is that they could include more libraries in some games, instead of just listing them on the game's page, this would give a better out of the box experience.
Bundling libraries with an application should only be done as a last resort when a library is not available on a system. Duplicating already available system libraries with an application is generally a bad idea.
avatar
Ganni1987: My only complaint is that they could include more libraries in some games, instead of just listing them on the game's page, this would give a better out of the box experience.
avatar
eiii: Bundling libraries with an application should only be done as a last resort when a library is not available on a system. Duplicating already available system libraries with an application is generally a bad idea.
To be fair, very few system libraries both maintain the requisite level of ABI stability and are packaged by distros which ensure ready access to earlier ABI versions.

The current balance is basically determined by that and is roughly equivalent to how so many Windows applications resolved DLL Hell by bundling their own DLLs.