Hi,

with its current behavious, game-data-packager is inconsistent from game to
game.

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.

Now, when you run e.g. "game-data-packager rott", you are asked to either pass
the "-w" option to automatically download the demo version from the net and
package it (very neat, BTW!) or specify the path to the demo ZIP file using the
"-f" parameter.

Now, on the other hand, run e.g. "game-data-packager heretic": A demo version
is also available for this game, but g-d-p does not support downloading it. It
does not even support packaging it, only the commercial version. And guess
what, you have to supply the path to the WAD file on the command line - without
an additional parameter.

I think this is pretty much messed up. I don't have an universal solution at
hand, but I think we could use this bug report as a discussion ground.
Furthermore I believe it should be possible to optionally download demo
versions for all games in g-d-p, if they are freely available.

 - Fabian

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.

I thought we might as well package Heretic, which was shareware, like doom, in
doom-wad-shareware. However we'll probably never manage to get a clear right to
distribute the shareware IWAD like the Doom one (where the original maintainer
saught specific permission from John Carmack himself).

Yeah, like the doom target too. In fact, checking all currently supported
targets, the following work if you pass a single argument (after g-d-p game):

  doom, doom2, plutonia, tnt, heretic, hexen, hexen2[*], quake

So that's 8 targets. The following require flags (-f or -w)

  rott, wolf3d, lgeneral[*]

3.

([*] - targets not in stable/testing/unstable: either in experimental or the
VCS.)

Personally, I like the way the 'quake' target works:
So it behaves like the 9 above if you pass one argument, but you can fine-tune
precicely what behaviour you want if you wish.

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.

I guess I don't disagree with that. Someone needs to do the work to implement
it though :) There's no point for Doom since we have doom-wad-shareware. So
there's at least heretic, hexen, hexen 2, quake, quake 3 which have demo
versions.

Am 01.11.2012 23:26, schrieb Jon Dowland:

It's not *that* in line, though.

rott and wolf3d require a specific set of data files to run, they do
not share the concept of a single WAD file. So, for single-WAD games
g-d-p expects the path to said WAD file if not other argument is given
and for multiple-data-files games it expects the path to a collection
of files. For rott and wolf3d that's currently the shareware ZIP file.
but what do we do for the registered versions,for which such a ZIP
file does not exist?

I think it's hard to align these two types of games (single and
multiple data files).

And strife, which vavoom supports.

  - Fabian

Arena demo PK3s is not compatible with ioquake3: the demo runs under
either the original retail engine or an even older prerelease (I'm not
sure which), whereas ioquake3 is an open-source fork of a later patch
for the retail engine. I believe this means you have to use special
command-line options to use the native-code game logic (which ioquake3
installs to /usr/lib/ioquake3/baseq3 but does not use), resulting in
something that is not network-compatible with either the "real" demo or
the retail game.

As a result, if you want to enable the Quake III Arena demo to work,
it'll need some development and testing.

One possibility (analogous to what happens in src:quake) would be to
make the launcher script check at runtime whether it has
/usr/share/games/quake3/baseq3/pak0.pk3 or
/usr/lib/games/quake3-demo/whatever and configure itself accordingly,
defaulting to the retail game if you have both unless --demo (or
something) is given, with a dependency on quake3-data | quake3-demo-data
| game-data-packager.

Another possibility would be to treat quake3-demo as a separate game,
built from src:quake3, with its own launcher, desktop file and icon.

I don't think it's a good idea to put the Q3 and demo data (baseq3, and
demoq3 or whatever it's called) in the same fs_basepath: there is code
in the engine to work out whether it is running the demo or the retail
game and alter its (global!) behaviour. Separating them into
/u/s/g/quake3 and /u/l/g/quake3-demo seems reasonable.

I say /usr/lib and not /usr/share because if we're using the native
code, we'll have native .so files under the fs_basepath. In
src:openarena I set the fs_basepath to /usr/lib/games/openarena, install
the native-code game logic there (in quake3-demo it could maybe just be
symlinked in from /usr/lib/ioquake3), and symlink in the PK3 files from
/usr/share/games/openarena (which is what's in the -data packages).

It is deliberate that the native-code game logic in ioquake3 is not in
the engine's default search path: we don't want it to interfere with
standalone games (OpenArena etc.).

    S

and make reasonable efforts to find the required files in that directory
automagically".

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.

The "main game" argument can actually be in one of at least two forms:
the mount point of a Quake III Arena CD-ROM (it knows about two
filesystem layouts from different versions) or the full path to
pak0.pk3. g-d-p makes a reasonable attempt to "do what I mean".

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 (including a CD mountpoint, an
installed copy, C:\Program Files\Steam that contains an installed copy,
/usr/share/games while you have quake3-data installed, etc.) and it'll
do the right thing.

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

    S

It is, but not impossible. In all cases something that did some guestimates
would be nice. SO e.g. even in the single-WAD case, if you pass a directory, is
it $dir/doom2.wad, $dir/DOOM2.WAD, $dir/foo/DOOM2.WAD (for foo being whatever
the dir is on the commercial CD-ROMs, I'm not sure) or even
$dir/SteamApps/.../doom2.wad  (for the case where the user is pointing g-d-p at
a mounted windows partition containing steam with the games installed)

Another wishlist bug :)

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

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.

Both pending for v39, as it happens.

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

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.

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

Done! (For all YAML games.)

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

It works.

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

Redirecting this to #691772 because I think this is getting way off
topic for a bug about Wolfenstein 3D support; please excuse the
resulting full-quoting.

I think I would prefer to get all the games into Python/YAML (which
means writing CD-ripping and lgeneral-processing code), *then* think
about how to make their command-line syntax consistent and optimal once
we know the technical constrains; and that's getting into the same sort
of thing previously discussed on #691772, so I'm going to repurpose
#691772 for that.
it's because they are :-P

The only reason I wrote those files was to keep the -w and -f
command-line arguments working for now. When we have all the games
converted and can see more clearly what features we do and don't need,
I'm seriously considering removing support for those arguments.

We should probably have a common --download/--no-download option (with
--download being the default) so you can tell gdp not to go and download
stuff automatically; but I would like to get everything YAML'd first,
because implementing new global options in the shell script wrapper
seems like wasted effort when we only have a couple of games that really
still need it, and those are hopefully on their way out.

I don't think the "Download %s" text is important. It's only there
because I needed the Python "plugin" for -w/-f anyway, and having
written that, the help text was trivial.
wrote:

As I said above, I think the time to sort this out is after everything
is Python/YAML.

Regards,
    S

Am Freitag, den 16.01.2015, 10:06 +0000 schrieb Simon McVittie:

- Fabian