Bug#691772: game-data-packager: Inconsistent from game to game

[Simon McVittie]

On Mon, 29 Oct 2012 at 16:31:30 +0100, Fabian Greffrath wrote:
> with its current behavious, game-data-packager is inconsistent from game to
> game.

Yes, but the Python/YAML stuff is getting towards solving this (by running
pretty much the same executable code everywhere, and having declarative
descriptions of what we want, plus extra Python code for strange
package-specific quirks).

> Take for example "rott" or "wolf3d": Demo versions exist for these two games
> and they are freely available on the net. There are also commercial versions
> available for purchase, but g-d-p does not support them.

I don't think "there exist games for which we support the (full|demo) version
but not the (demo|full)" version is a useful reason to keep a bug report open,
because it's likely to remain true for quite a long time (if only because
not all contributors own all the games). A bug report per missing game
(that someone cares about) makes sense: that's something that a contributor
can close in a reasonable time.

> We should support the commercial data as well as the free data. So that's two
> wishlist items: commercial wolf3d support and commercial rott support.

Both pending for v39, as it happens.

> I'd be in favour of changing rott, lgeneral and wolf3d to not require '-f' and
> treat a single argument as a path if supplied, in line with the other targets.

Done in v38 for rott and wolf3d. lgeneral is part of #775083.

> So there's at least heretic, hexen, hexen 2, quake, quake 3 which have demo
> versions.

Heretic works.

The Hexen demo is currently commented out because it crashes chocolate-doom,
but the code is there. Maybe it works in doomsday. #775483.

Hexen II is a valid wishlist bug, which I've opened. #775484.

Quake works.

Quake III Arena is a valid wishlist bug, which I've opened, but needs
help from the quake3 and ioquake3 packages before it's actually playable.

On Fri, 02 Nov 2012 at 09:45:05 +0100, Fabian Greffrath wrote:
> And strife, which vavoom supports.

Part of the mega-bug #737137, I'll clone it.

On Fri, 02 Nov 2012 at 09:21:54 +0000, Simon McVittie wrote:
> The simple but harder-to-implement answer is "expect a directory name,
> and make reasonable efforts to find the required files in that directory
> automagically".

Done! (For all YAML games.)

> quake3 expects two arguments: one for the main game, and one for the
> patch (point release). I think this is probably wrong; I'm tempted to
> change it so g-d-p produces quake3-data (pak0.pk3) from a retail Q3
> installation, CD, or any directory containing baseq3/pak0.pk3, and
> quake3-patch (the rest) from either the point release or any directory
> that happens to contain the correct PK3 files.

For now, I decided against this, and kept it all in quake3-data.

> I'm actually tempted to think it should do the equivalent of "find
> ${dir} -iname pak0.pk3" so you can point it at anything that looks
> vaguely reminiscent of Quake III Arena

It works.

> Also vaguely on my to-do list: make g-d-p able to produce
> quake3-team-arena and quake3-team-arena-patch.

Done. (The patch is part of an updated quake3-data, which is a dependency;
but that's OK because gdp knows how to regenerate quake3-data from
installed files.)

    S