Linux 3.17 (which was released just a couple of weeks ago) added support for the Xbox One controller - rumble doesn't work though. However there probably aren't too many games that support the Xbox One controller out of the box. So far I had only success with Rogue Legacy, which I play a lot right now for exactly that reason. ;o

Hi Linuxers,
Just a word of warning, I recently found out that several recently updated installers generate lots of Runtime errors under Wine; And /nogui does not work as a workaround since it generates its own load of Runtime errors (not the same, but still). Actually some fellow Linuxer got replied by GOG support that /nogui was no longer officially supported at the moment.

So, to keep it short, be aware that games that do not officially have Linux support here may not install nicely, even if the game itself has good rating in the WineHQ's AppDB, tested using either the original installer or older GOG installers.

Oh, great. That combined with the fact that all GOG installers cannot be extracted with Innoextract makes me a sad panda.

Thanks for the warning though.

edit. See thread: http://www.gog.com/forum/general/on_gnulinux_has_anyone_be_able_to_extract_the_rar_innosetup_installers

Thanks for the heads up - I missed all that since I didn't install anything recently. Did GOG provide any info on that password? And why do they use it? It smells DRM.

Whoa, the only point I can see in using password protected compression is to enforce the use of the GOG installer for installation.
I have 460 games here, most do not have Linux support yet, some may never have.
If the installer becomes not Linux friendly and there's no technical workarounds, it could become very silly.

Trying not to look alarmist here, but still, I'm a bit worried by current technical heading...

I haven't seen any official word about it. Currently the majority of Linux gamers still have a Windows install available in one form or another which makes me rather skeptical it's DRM related. They can simply run the installer, as it includes the password, on Windows, and copy the files & etc over. Complete speculation on my part, but I believe they updated to a newer version of Inno Setup with these knobs automatically turned on.

Does it run well under WINE?


Anyone sent in a support ticket about this? While using the installer in this fashion is completely unsupported, assuming this wasn't deliberate on GOG's part, they may not even be aware of it.

Like petchema said, I think it might be because they want to enforce using the installer. That way user has to agree to the legal stuff.

Just like they did with the LucasArts games for Linux - only .deb available because that way user has to agree to the legal stuff (just don't tell them the .deb can be extracted as well). :)

I have no problem with this if the installers would at least work in Wine. I haven't tried any of the new ones myself.

Thanks, I'll try that if I run into problems with other methods.

Yes, just open the terminal and go like: ./innounp.exe -x gog_game_name.exe

I opened a lot of the modern GOG installers with it, no problems at all.

By the way, which games exactly are affected by this? I just extracted Windows installer of Indiana Jones and the Fate of Atlantis with innoextract just fine. So I don't think it's what you said above.

As far as I know, LucasArts games officially available for Linux.

See: http://www.gog.com/forum/sam_max_hit_the_road/wheres_the_linux_tarball/post26

I don't know if it's this or something else. Maybe it's just the way (a newer version of) InnoSetup does things.

Since Windows installer of Indiana Jones and the Fate of Atlantis extracts normally with innoextract (and deb does produce EULA notice) I don't think the need for EULA is related to password found in some other installers.

xz 5.2.0 now includes parallel compression / decompression.

http://git.tukaani.org/?p=xz.git;a=blob;f=NEWS;hb=HEAD

GOG should really use tar.xz created with parallel compressor instead of tar.gz. Please vote here if you didn't yet:
https://www.gog.com/wishlist/site/use_better_compression_for_linux_tarballs_for_example_tarxz

I ran some tests on Wasteland 2 when building .deb packages, here is what I got (on a 3.4GHz CPU):

compression method = none (tar)
final size = 20G
time = 16min

compression method = gzip
final size = 11G
time = 47min

compression method = xz
final size = 8.4G
time = 165min

Keep in mind that I used a xz version without support for multi-threaded compression, the time it takes for compression should several times shorter with version 5.2.0.
All values are for default compression levels used by dpkg, not the highest allowed by the compression method.

In your test you should also measure decompression time. xz without multithreading is bad for large packages. Such huge wait time during installation is just not user friendly.