Serfaboy

I've updated the Linux patch of UT99 to v451, you can read more about it here: http://www.gog.com/forum/unreal_series/unreal_tournament_99_goty_easy_setup_for_linux

Looks like Trine 2 is affected by infamous bugs related to XFS. Another one to the list... It's like 6th or 7th game for me already (last time I reported it for Race the Sun and developers said they'll look into it). I'll try contacting Frozenbyte.

I reported the XFS bug for Trine 2 here: http://frozenbyte.com/board/viewtopic.php?f=17&t=27349
Let's see what they'll say.

For GOG: this bug is really common. Your QA should make a 2TB XFS partition for testing any incoming Linux release. This way you can catch such bugs much earlier and direct right to developers to fix them.

Just for the reference, quite a number games on GOG are affected by this bug till this day. For instance Brutal Legend and Clarc. Even Witcher 2 was affected by XFS related bugs :) (not only by this but also by another one related to directory reading), but Virtual Programming fixed all that in their latest releases.

We should probably make a GOG mix for affected games ;)

Here you go: https://www.gog.com/mix/linux_games_with_large_xfs_partition_bug

Feel free to ping me to add to the list if you know other confirmed cases, or one of those games will get fixed before I'll notice.

I've having problems getting Trine2 to run under LMDE 2. Here is the error I get running the start.sh...

Running Trine 2 - Complete Story
nohup: redirecting stderr to stdout

Are you using XFS too?

EDIT: there is a news post.

Seems pretty big change with linux gog files today, now there are .sh installers for all games. Ran lgogdownloader and all my games (downloaded as tar.gz) are not present on server anymore (same on the website).

Downloaded one new .sh to test, it's a windows type installer with eula, install location and option to create shortcuts. Default install location is ~/GOG GAMES/, and there is an uninstall script.

Seemed to work fine (am on manjaro xfce), I tested the game escape goat and I notice in install location fles relating to mojosetup, which I believe is what many humble store games use.

But I don't think I like it being the only option, tar.gz files suited me fine and are what I thought I was buying - could manipulate files easily with terminal and scripts. It could be part of some renewed approach to linux though by gog to smooth out the process if they've been having problems, which would be nice given the many missing builds here recently.

I’m going to study these new installers for my ./play.it project, and I’ll share the method to manipulate them easily once I’ve found it.
Blind guess : you should try 'unzip' on them, it works to extract the data from the Humble Bundle MojoSetup installers.

I usually don't prefer installers either, and tarballs are the simplest form. We need to find a way to extract those installers, or to figure out what they use. If it's some open source installer with known behavior, it might be OK.
Usually running '7z x <package>' works pretty well, since 7z supports a lot of archive formats.

UPDATE:

OK, I see it's using Mojosetup. Just checked Don't Starve one. Mojo is made by Icculus and it's a good tool:

https://icculus.org/mojosetup/
https://hg.icculus.org/icculus/mojosetup/

Some users like such seamless installation and tool is open (but note that it relies on some quirky GTK stuff which can be annoying to some). 7z x or simple unzip work fine on these packages, even though they for some reason show that they use gzip, that's somewhat confusing. You can run the script with --info to see some details.

GOG could announce that for Linux users instead of silently pushing such stuff however.

I uploaded a script allowing to build a DEB package from the new MojoSetup installer for Shadowrun Returns.
All feedback is welcome ;)

Very much do not want. I now have cause to curse GOG for forcing installers on everything rather than praising them for forcing tarballs on things that, through Humble, I can tell the developers would prefer installers for.

Getting MojoSetup stuff installed, copying it to /mnt/buffalo_ext/games, and then uninstalling to clear out the cruft it places in my homedir is far more hassle than unpacking a tarball.


(Plus, of course, I'll probably want to set up a chroot to capture all changes the installer makes to be absolutely sure the process doesn't leave anything lying outside /mnt/buffalo_ext/games/)

It makes me very glad I downloaded all my previous purchases as soon as I had 'em and that I can use innoextract to grab the DOSBox and ScummVM data files out of the Windows installers for stuff I buy going forward.

Of course, given that some of my Humble-only purchases have been doing this all along, I'll probably use this as an impetus to investigate writing some kind of innoextract-alike for MojoSetup.

(Use shlex from the Python standard library to parse metadata out of the makeself-based first stage without executing it, use that metadata to copy out the gzipped tarball, and then investigate further from there.)

The only reason zip tools work on them is because Zip is robust enough to just ignore the makeself stub and MojoSetup tarball that precede the Zip file.

They show up as gzip because MojoSetup is implemented as follows:
1. .tar.gz up MojoSetup itself and then feed it into makeself to stick a shellscript stub onto the front.
2. Concatenate a zip file full of stuff to be installed onto the end.

...so it looks like this

[shell stub][mojosetup tarball][game data zip file]

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

(It uses Python's shlex to scrape the offset variables out of the stub and then extracts any and all archives makeself defines. It may not work for all versions of makeself for the same reason innoextract doesn't, but I hope it'll be at least as robust as innoextract.)

For Escape Goat, it dumps the following:
1. a "1.tgz" containing MojoSetup itself. (TODO: Don't assume gzip. Choose file extension by header detection.)
2. a "2.bin" which is actually a Zip file (detected as a mismatch between the actual length of the file and how long makeself's internal metadata expects it to be)

Nope, boring ole ext4.

Thanks, I tested your tool - it works nicely for Don't Starve.

You can try stracing the game and see what is going on.