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

Simon McVittie smcv at debian.org
Fri Nov 2 09:08:18 UTC 2012


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



More information about the Pkg-games-devel mailing list