Bug#691772: game-data-packager: Inconsistent from game to game
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 +, 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
Am Freitag, den 16.01.2015, 10:06 + schrieb Simon McVittie: The Hexen demo is currently commented out because it crashes chocolate-doom, but the code is there. Maybe it works in doomsday. #775483. It does: http://dengine.net/dew/index.php?title=Libhexen - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
Am 01.11.2012 23:26, schrieb Jon Dowland: 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. 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). 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. And strife, which vavoom supports. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
On 01/11/12 22:26, Jon Dowland wrote: On Mon, Oct 29, 2012 at 04:31:30PM +0100, Fabian Greffrath wrote: Furthermore I believe it should be possible to optionally download demo versions for all games in g-d-p, if they are freely available. So there's at least [...] quake 3 which have demo versions. Note that, to the best of my knowledge, the bytecode in the Quake III 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
On 02/11/12 08:45, Fabian Greffrath wrote:
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?
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.
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
On Fri, Nov 02, 2012 at 09:45:05AM +0100, Fabian Greffrath wrote: Am 01.11.2012 23:26, schrieb Jon Dowland: 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. 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). 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) And strife, which vavoom supports. Another wishlist bug :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
On Mon, Oct 29, 2012 at 04:31:30PM +0100, Fabian Greffrath wrote: 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. 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. 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. 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). And guess what, you have to supply the path to the WAD file on the command line - without an additional parameter. 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: $ game-data-packager quake game-data-packager quake arguments: game-data-packager quake path -m path path to a mounted Quake CD-ROM -d path path to an unpacked Quake directory -s path path to a Quake shareware ZIP -mp1 path path to an unpacked Scourge of Armagon directory or a mounted Scourge of Armagon CD -mp2 path path to an unpacked Dissolution of Eternity directory or a mounted Dissolution of Eternity CD pathpath to any of the above (game-data-packager will guess) 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 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. 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. Furthermore I believe it should be possible to optionally download demo versions for all games in g-d-p, if they are freely available. 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691772: game-data-packager: Inconsistent from game to game
Package: game-data-packager Version: 30 Severity: normal 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 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (901, 'testing'), (502, 'unstable'), (501, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages game-data-packager depends on: ii dynamite0.1.1-2 ii fakeroot1.18.4-2 ii p7zip-full 9.20.1~dfsg.1-4 ii unzip 6.0-7 game-data-packager recommends no packages. Versions of packages game-data-packager suggests: pn lhasa | jlha-utils | lhz-archiver none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
