Quadrilateral Cowboy: list both 'Humble Indie Bundle' and 'Steam' distribution variants

I've inspected the differences between these two distributed versions of the game data locally, and the changes are some textual corrections in one of the menus - they're the same game apart from that.

0. This game needs to be added to "data/meson.build" file. I don't know why meson needs this, and I easily forget about it too.

1. The build will then fail because of the base/someting.pk4 vs something.pk4 dispredency. Just stripping the "base/" is enough.

2. You need some "alternatives" stanza boilerplate in "files:"

  pak000.pk4:
    alternatives:
    - pak000.pk4?humbleindiebundle
    - pak000.pk4?steam

3. If these pk4 files are indeed zip files, they could be compared with diffoscope tool; just give it a try.

3bis) but then it means that upstream didn't followed the spirit of IdTech games. -> having one immutable pak000.pk# and pak001.pk# with the patch. Patch could then also be cumulative. ... and could change pak000.pk4 again un the future...

added 3 commits

• f9c5464c - Add quadrilateralcowboy to data/meson.build
• 039817f1 - Remove directory prefix from quadrilateralcowboy pk4 checksum filenames
• 8088227d - Add 'files' map listing the variants of the pak000.pk4 game data file available

Compare with previous version

diffoscope

In this case, diff -r <dir-one> <dir-two> was enough - but I do like diffoscope from what I've seen it do for reproducible build differences, definitely useful.

having one immutable pak000.pk# and pak001.pk# with the patch

Yep - perhaps simply a case that they weren't aware of that ability, and/or slightly different game data builds were used for different distribution channels.

It's possible that I may want to make some further tweaks to exactly the same menu definition text file -- in particuar, to remove a bug report feature that won't work in the currently-configured package's engine -- I'm considering using a pak001.pk4 or similar (pak900.pk4?) to patch that.

Thank you for the help and reviews.

added 1 commit

• b3d69635 - Documentation: add a step mentioning the 'data/meson.build' file

Compare with previous version

A tiny patch to fix the build:

 install:
-   - base data
+   - pak000.pk4

Yes your engine package could provide a pak001.pk4 file to customize the game.

Thanks - almost ready to push that commit.

One question, though: with that change in place, will the checksums still be verified? (adding pak000.pk4 makes sense to me - but will the group data no longer be used?)

Ah. I see from another file that it's possible to add size and md5 keys within a file. I might do that instead of using groups.

added 2 commits

• 3dc9473c - Fixup: set pak000.pk4 as an install requirement
• a4e46132 - Add SHA512 hashes for qc game data files

Compare with previous version

added 1 commit

• 2c8356f9 - Nitpick: use less-crazy YAML syntax

Compare with previous version

size& md5: over time there were changes in the supported syntax, some old style remain but could/should maybe be deprecated.

merged

mentioned in commit 6e7c2729

Yes your engine package could provide a pak001.pk4 file to customize the game.

Maybe an unnecessary reply from me here, but to communicate what I'm thinking about this at the moment:

To begin with, I think that the safe/conservative approach I'd like to follow will be to package 1) the game engine (since it is definitely open source), and 2) the unmodified game data (as we do here), but not to provide additional customizations within Debian (even contrib).

That may change over time, but initially it feels like the path to take.

I think that the safe/conservative approach I'd like to follow will be to package 1) the game engine (since it is definitely open source), and 2) the unmodified game data (as we do here), but not to provide additional customizations within Debian (even contrib).

I would tend to agree. If you do get into making changes, then you're effectively providing an unofficial game patch (like the ones people do for Skyrim or whatever), and I'd prefer game-data-packager not to be in the business of doing that: the line I personally draw is that if the canonical (retail, etc.) version is known to be particularly problematic, we'll package other people's unofficial patches (like we do for Unreal and UT99) or include game-engine maintainers' game engine integration stuff (like we do in yamagi-quake2); but if we do that then they should generally come from an "upstream" outside Debian (possibly you!), or be treated like a mod (like the way we deal with third-party Doom levels), or both.

If you're applying customizations in a game with a Quake-style search path, please use a name that doesn't collide with the obvious filename to use for a Quake-style patch release, less like pak001.pk4 and more like x_deb_patch1.pk4 - or even talk to the game's developer about getting those customizations to be official?

Thanks, @smcv. Although it's a slight tangent: based on that I'm also going to update the upstream source reference in the game engine packaging to point to my fork of the game's repository, instead of the original game developer's repository (at least until the changes I've offered back are accepted).

As an additional note: the engine is a modified Doom3 engine, you could check there if there are any Debian-patches relevant there.

(there are in fact 2 Doom3 engines in Debian: doom3 and the BFG version)

@tobias Frost