Package Details: ut2004-gog 3369-5

Git Clone URL: https://aur.archlinux.org/ut2004-gog.git (read-only, click to copy)
Package Base: ut2004-gog
Description: Unreal Tournament 2004 ECE native Linux version with data via GOG
Upstream URL: https://www.gog.com/game/unreal_tournament_2004_ece
Licenses: custom
Conflicts: ut2004, ut2004-steam
Submitter: jmsq
Maintainer: jmsq
Last Packager: jmsq
Votes: 3
Popularity: 0.000088
First Submitted: 2021-08-19 08:40 (UTC)
Last Updated: 2022-06-28 07:15 (UTC)

Pinned Comments

jmsq commented on 2021-08-19 08:49 (UTC) (edited on 2021-08-30 12:31 (UTC) by jmsq)

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

Latest Comments

1 2 3 Next › Last »

Tomatopaste commented on 2022-09-03 01:08 (UTC)

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!

cgarz commented on 2022-07-23 23:58 (UTC) (edited on 2022-07-24 00:00 (UTC) by cgarz)

@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.

jmsq commented on 2022-07-19 09:13 (UTC)

@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.

cgarz commented on 2022-07-01 04:13 (UTC) (edited on 2022-07-06 23:07 (UTC) by cgarz)

@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.

jmsq commented on 2022-06-30 06:04 (UTC) (edited on 2022-06-30 06:04 (UTC) by jmsq)

@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.

cgarz commented on 2022-06-28 07:48 (UTC)

@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.

jmsq commented on 2022-06-28 07:18 (UTC)

@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.

cgarz commented on 2022-06-21 05:21 (UTC) (edited on 2022-06-21 05:35 (UTC) by cgarz)

Had a fair few issues but got there in the end.

Not sure if this is because I was using the offline installer files instead of gogdownloader but Innoextract was extracting all files into an app subfolder.
Fixed by adding:

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

Below the extraction in PKGBUILD.
I also added the -m argument to stop it from adding the other subfolder tmp to the package.

Had issues with sound, it seems that somewhere between openal 1.21.1 and 1.22.0 something changed that UT'04 doesn't like.
Tried the latest master (even with the recent as of a few hours ago 1.22.1 version bump) but unfortunately still no sound.
Fixed by compiling from the openal-soft-1.21.1 tarball and overwriting the symlink in /opt/ut2004/System with libopenal.so.1.21.1 from it.

I also noticed that the CDkey is stored in the goggame script file. So I added:

grep -FB1 CDKey /opt/ut2004/goggame-1207658691.script | grep -Po '"valueData": "\K[A-Z0-9-]*(?=",)' > "$HOME"/.ut2004/System/CDkey
chmod 600 "$HOME"/.ut2004/System/CDkey

to the first run section in ut2004.sh.

Only other issues were mismatching checksums but I figure that was from using an offline installer. All files verify fine with github.com/DorianRudolph/gogverify.

jmsq commented on 2022-05-16 10:40 (UTC)

@lazycrypt thanks for the find; I'm updating the startup script to copy over those files if the ~/.ut2004 directory doesn't already exist; this should cover the fresh install case without unexpectedly nuking existing configs.

grabarz commented on 2022-05-15 00:15 (UTC)

Solution provided by @lazycrypt works on my system.