Arch Linux User Repository

For those who haven't used lgogdownloader with a GOG AUR package before, here's how you set it up.

Add 'gogdownloader::/usr/bin/lgogdownloader --download-file=%u -o %o' to the DLAGENTS section of /etc/makepkg.conf

Thanks @jebez for that archive link. I was able to compare my offline installer against it to work out why everything was getting extracted to an app subfolder. It seems my installer is just older and extracts files in the app section instead of the tmp section of the inno script. Which I think explains why innoextract put everything in an app subfolder forcing me to manually move it all up a level.

@jmsq You might be right about having to skip checksums on the installer files. The comparison seems to confirm my suspicion that GOG installer files can vary quite a bit, even though all actual game files might be identical once extracted. Things like the adverts that display when installing can be different, as well as differences in what files are present in tmp or differences in the inno install script.

Are you able to get files with a different checksum from gogdownloader? I'd be interested to see if they can change despite the link never changing.

I got both versions to match well against what gogverify expects by deleting the tmp dir and moving some stuff around like so:

My version:
   rm -r tmp; mv app/* . && rmdir app; mv __support/app .
archiveorg version:
   rm -r tmp; mv __support/app/System app; mv app/Benchmark .

That just left these small issues gogverify mentions which are probably fine:

My version:
   Unexpected files: webcache.zip  __support/scriptinterpreter.exe
archiveorg version:
   Unexpected files: __redist/ISI/scriptinterpreter.exe  app/goggame-1207658691.ico  app/webcache.zip  commonappdata/GOG.com/supportInstaller/uninstall.dll
   Expected files: Prefabs (directory): Missing

If anyone wants to compare the full differences between the installers I have uploaded post extraction checksum file lists and the inno install scripts here:
https://gist.github.com/cgarz/d4873329a564d77c19c8cc181db4e525

@jebez That's not how this works: this package is still usable and available for existing owners of the GOG version of ut2004, even after it has been delisted it can still be downloaded from existing owners' libraries. If you want a version of this that pulls from a different source, I'd suggest branching the package and creating a ut2004-archiveorg or equivalent that provides/conflicts with the other ut2004 variants (e.g. ut2004-gog, ut2004-steam) as necessary.

This game is now abandonware, delisted from GOG on December 23, 2022 https://www.pcgamingwiki.com/wiki/Unreal_Tournament_2004#Availability :

setup_unreal_tournament_2004_1.0_(18947)-1.bin

setup_unreal_tournament_2004_1.0_(18947).exe

are now unavailable from GOG, but available here:

https://archive.org/download/unreal-gog-pack

Hence update ut2004-gog, remove https://aur.archlinux.org/packages/lgogdownloader as dependency.

I'm joining late to the party, but I would also like to confirm that the latest patch works. Good job and thanks a lot guys!

@jmsq Yea looks like it, I checked out a few places and all cdkeys seem to be coming up the same.

I agree that if lgogdl consistently gives the same hashes then its better to have them.
Though have you checked if hashes from another accounts match? Perhaps the installer has per user stuff or something that would change the installer part but not the game data.

Another thing is that innoextract hardcoded path suffix issue. For me it extracts into $pkgdir/opt/ut2004/app instead of $pkgdir/opt/ut2004.

I recently installed it on another computer and still had to add some PKGBUILD lines just after innoextract to move stuff up a level like I did when installing on my main:

# Move extracted files out of innoextract hardcoded folder
mv "$pkgdir/opt/ut2004/app/"* "$pkgdir/opt/ut2004"
rmdir "$pkgdir/opt/ut2004/app"

Thankfully though on that computer openAL seems to work fine without downgrading.

Oh and ut2004.install can be removed now that the CD key is automatically handled.

@cgarz sorry about the delay; I just got around to checking this. My script does in fact have that same checksum, so it's likely they're just using the same cdkey for everyone these days. The gog bin installer file still has a different checksum compared to yours and gogcheck though. Since lgogdownloader is my recommended install approach for easier upgrades through AUR helpers, I'll probably leave that as-is unless you're getting a different checksum through that tool specifically.

@jmsq Actually the CDKey's may all be the same after all.
I noticed when using gogdb that there is an md5sum for the script file listed in a GOG manifest for the current build. It's d21c93c6b144b92ad0d373c31d97ff2d which matches mine. Does your goggame-1207658691.script md5sum also match that?

This is the gogdb page for the current build: https://www.gogdb.org/product/1207658691/build/50996559401806461
The manifest id for the script file is 917d47754b5b55e99de8e96894c325b5
This can be downloaded from GOG from:
https://cdn.gog.com/content-system/v2/meta/91/7d/917d47754b5b55e99de8e96894c325b5.
However it is zlib compressed, you can use pigz or zlib-flate to decompress it.
Alternatively you can hard code a gzip header to get gunzip to decompress enough of it to at least see the md5sum:

printf '\x1f\x8b\x08\x00\x00\x00\x00\x00%s' $(curl -s 'https://cdn.gog.com/content-system/v2/meta/91/7d/917d47754b5b55e99de8e96894c325b5') | gunzip -c

When you were checking your CDKey md5sum did you use printf key | md5sum? If you were to use echo instead then it would come out as 0039e6f5bcd1bf877ac0ec2516670e33 due to echo inserting a newline character.

I'm not sure why both my offline installer files are different but the extracted files verified fine with github.com/DorianRudolph/gogverify, which is where I learned the location of GOG manifest files.

I've also now tested github.com/hippie68/gogcheck which seems much more extensive. It verifies the exe file PE checksum + digital signature and the data file md5sum as well as verifying all the files without them needing to be extracted unlike with gogverify.
I've yet to look through its code to see where it pulls the md5sum of the data file from but it says that setup_unreal_tournament_2004_1.0_(18947)-1.bin should be 2bef5dd25136ef670c64acbf0ae8ce2a which matches mine.

Edit: Upon reading the script it looks like GOG setup files have a #GOGCRCSTRING string towards the end of them. That is prefixed with the md5sums of all bin files and then a 2 digit number for how many bin files there are. Which gogcheck just pulls out with grep and chops up.
And with the signature check even if someone edited any checksum in the exe file for malicious ends the signature verification flags that. Pretty cool stuff.

Edit 2: Looks like https://lutris.net/games/install/934/view also lists the CDKey and it matches mine.

@cgarz: good point about the checksums; my key has the same first and last digits but a different md5sum. The only way I can see to fix this is unfortunately just skipping the checksums entirely on the installer files. Do both the exe and bin files have different checksums for you or just one of them?

As for openal, I'm not sure what's going on there; it's possible some recent change broke it for certain setups, but unfortunately I'm not able to reproduce it on my systems so far.

@jmsq Just tested 1.22.2 there and for me there is no sound when using it.
Recompiling with 1.21.1 restores sound for me.

I'm no expert with how gog or arch does things but if the CDKey is included in everyone's installer, unless the CDKey is the same for everyone, then afik the installer checksum should always be different. The md5sum of my cdkey for example is ade3c951b1170714c15188bbdc7c0ce5, that is, without quotes, and including hyphens, beginning with 3 and ending with 4.

@cgarz thanks for sharing your experience and tips; I've added the cdkey setup to the script.

As for extraction paths and checksums, lgogdownloader downloads the offline installers directly, so I'm a bit surprised there's differences when downloading the files manually.

As for openal, I'm not able to replicate the issue. However Arch is now on 1.22.2 so maybe something got fixed upstream.