played around with the innoextract source code and managed to hack in some basic support for the new installers
https://github.com/immi101/innoextract/tree/gogextract just grab the source, and use the same procedure as for the original to compile
$ mkdir build && cd build
$ cmake ..
$ make
then pass the --gog flag to tell it to decompress the galaxy data, e.g.
$ ./innoextract --gog -e -m -d out ~/setup_eador_genesis_1.05.2_\(19162\).exe
the installers support conditional installs depending on game language, os type(32/64 bit) and windows version, so there are three more command line parameters to set these.
with no parameter given it defaults to: --lang en-US --winver win7 --osbits 64
caveat: I haven't found an updated installer in my library that actually makes use of this, so this may not work at all :p
TODO:
- handle dependencies like scriptinterpreter.exe (if we even need that ?!?)
- test more than one installer ;)
side note: eador genesis just crashes with wine 3.0 for me :( pretty sure that this game used to work at some point, hm
immi101: the script may be more complicated, but they only have to write that once. Once it is working they have the added benefit that for every game update they only have to package the data once and then push out the same data set over galaxy and into the offline installer. sharing work load & aiming for consistent data between the two distribution channels seems like a sensible development goal.
(obviously without any detailed knowledge about their work flow it's hard to make a real judgement about this change)
mk47at: The new way is very inefficient in terms of installer size and install time: Compressing with zllib and then with lzma2 may result in a larger overall size than only compressing with lzma2, e.g. “Snapshot“ which becomes about 1 % larger that way.
as far as I can tell the galaxy data is only compressed with zlib. it's not compressed twice. While that may result in a bigger file size (compared to LZMA2) depending on the game I doubt it would be slower. if anything zlib should be faster than lzma I think.