Debian Bug report logs - #592965
openarena: uses incompatible 0.8.5 game logic when connected to 0.8.1 servers, even if sv_pure 1

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openarena: uses incompatible 0.8.5 game logic when connected to 0.8.1 servers, even if sv_pure 1

Date: Sat, 14 Aug 2010 15:54:47 +0100

Package: openarena
Version: 0.8.5-1
Severity: normal

As a result of the way in which we redirect from fake QVM bytecode to native
code, Debian openarena clients will always use the cgame logic from the latest
version of OpenArena. When a 0.8.5 client joins a 0.8.1 server, this leads to
the client disconnecting with

    ERROR: CG_RegisterItemVisuals: itemNum 70 out of range [0-60]

probably due to some incompatibilities between 0.8.1 and 0.8.5 game/bg_*.c.
I'm a bit confused by this, because the failure mode seems as though it ought
to be the other way round: 0.8.5 has *more* items.

You can tell the server is not 0.8.5 when this is logged:

    /usr/lib/games/openarena/baseoa/pak6-patch085.pk3 (559 files)
        not on the pure list

Upstream, the client will run bytecode from the newest available PK3 file;
when running on a "pure server" (sv_pure 1), the client isn't allowed to
load the PK3 for the 0.8.5 patch, and will fall back to the original 0.8.1
version. This wouldn't work on a server with sv_pure 0, where clients would see
exactly the same failure mode we do.

We can't distribute the upstream-supplied QVM bytecode in Debian main, since
it can't be compiled with a Free compiler, so we replace it with a stub
version that is interpreted as "go and load the equivalent native code
instead". However, we currently only ship native code corresponding to the
newest version of the QVM.

We could solve this, but the solution is pretty horrible:

* in the openarena binary package, ship native code for both the 0.8.5
  and 0.8.1 versions; I think we only need cgame - the "client game" logic run
  on clients - and not ui or qagame, but that still requires duplicating the
  source tree, and if there are bugs in 0.8.1 we'll be stuck with them

* when redirecting from a fake QVM file to native code, embed a suffix in the
  fake QVM file ("0.8.1" and "0.8.5", say), and prefer to load
  cgame0.8.1x86_64.so, falling back to cgamex86_64.so (which would be a
  symlink to the latest version at all times)

Regards,
    S

Message #10 received at 592965@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 592965@bugs.debian.org

Subject: Re: openarena: uses incompatible 0.8.5 game logic when connected to 0.8.1 servers, even if sv_pure 1

Date: Sat, 21 Aug 2010 16:41:56 +0100

[Message part 1 (text/plain, inline)]

On Sat, 14 Aug 2010 at 15:54:47 +0100, Simon McVittie wrote:
> When a 0.8.5 client joins a 0.8.1 server, this leads to
> the client disconnecting with
> 
>     ERROR: CG_RegisterItemVisuals: itemNum 70 out of range [0-60]
> 
> probably due to some incompatibilities between 0.8.1 and 0.8.5 game/bg_*.c.
> I'm a bit confused by this, because the failure mode seems as though it ought
> to be the other way round: 0.8.5 has *more* items.

I think it might just be that the 0.8.5 client code, when running against an
0.8.1 server, is interpreting player_state->stats[] members wrong:
STAT_PERSISTANT_POWERUP (sic) doesn't exist in 0.8.1, so STAT_WEAPONS (a
bitfield) will be interpreted as STAT_PERSISTANT_POWERUP by 0.8.5 client code,
causing a disconnect if you pick up a high-numbered weapon and the weapons
bitfield exceeds the length of the bg_itemlist.

This is originally an incompatibility between Quake III Arena (baseq3) and
Team Arena (missionpack/#define MISSIONPACK): baseoa 0.8.1 is a mixture
of baseq3 and a small amount of missionpack, whereas 0.8.5 has more of the
missionpack changes.

The other incompatible change I've found is that items (the persistent
powerups, i.e. "runes", plus Kamikaze and Invincibility) are inserted into
the *middle* of the bg_itemlist. Indexes into bg_itemlist are part of the
network protocol, so that's A Bad Thing™.

> Upstream, the client will run bytecode from the newest available PK3 file;
> when running on a "pure server" (sv_pure 1), the client isn't allowed to
> load the PK3 for the 0.8.5 patch, and will fall back to the original 0.8.1
> version. This wouldn't work on a server with sv_pure 0, where clients would
> see exactly the same failure mode we do.

As I predicted, impure servers suffer from the same failure mode with bytecode:
http://openarena.ws/board/index.php?topic=3717.0

> We could solve this, but the solution is pretty horrible:
> 
> * in the openarena binary package, ship native code for both the 0.8.5
>   and 0.8.1 versions

We can actually just have a #ifdef that reverts some of the 0.8.1 changes.
I attach patches.

592965-data.diff is for openarena-data, and is not in the svn repository.

The other two patches are for openarena, and are they're also in the git
repository as the 592965-081-compat branch.

> * when redirecting from a fake QVM file to native code, embed a suffix in the
>   fake QVM file ("0.8.1" and "0.8.5", say), and prefer to load
>   cgame0.8.1x86_64.so, falling back to cgamex86_64.so (which would be a
>   symlink to the latest version at all times)

I actually embedded a directory name instead; the build process of
openarena-data made it easiest to use the PK3 filename, so I did.

With these patches, when running on an 0.8.1 pure server, we'll load
pak0/cgamex86_64.so (or appropriate for the architecture), which is now built.

When running on an 0.8.5 pure server or on any impure server, we'll try
pak6-patch085/cgamex86_64.so (which isn't actually built), then
fall back to ./cgamex86_64.so, which I intend to keep as the latest version.

If 0.8.6 is incompatible with 0.8.5 in a similar way, we'll have to start
producing pak6-patch085/cgamex86_64.so too.

Regards,
    Simon

[592965-data.diff (text/x-diff, attachment)]

[0001-Add-patches-to-work-around-OA-0.8.1-to-0.8.5-network.patch (text/x-diff, attachment)]

[0002-Install-0.8.1-compatible-binaries-to-a-subdirectory.patch (text/x-diff, attachment)]

Message #15 received at 592965@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 592965@bugs.debian.org

Subject: Re: openarena: uses incompatible 0.8.5 game logic when connected to 0.8.1 servers, even if sv_pure 1

Date: Sat, 21 Aug 2010 19:37:14 +0100

forwarded 592965 http://openarena.ws/board/index.php?topic=3717.0
tags 592965 + patch
severity 592965 important
thanks

I think we can consider this to be 'important' severity, since there are still
quite a few 0.8.1 servers around and a patch isn't too difficult. I'm
clarifying the situation with upstream before asking for a freeze exception.

    Simon

Message #26 received at 592965-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 592965-close@bugs.debian.org

Subject: Bug#592965: fixed in openarena 0.8.5-4

Date: Wed, 25 Aug 2010 09:47:36 +0000

Source: openarena
Source-Version: 0.8.5-4

We believe that the bug you reported is fixed in the latest version of
openarena, which is due to be installed in the Debian FTP archive:

openarena-server_0.8.5-4_amd64.deb
  to main/o/openarena/openarena-server_0.8.5-4_amd64.deb
openarena_0.8.5-4.debian.tar.gz
  to main/o/openarena/openarena_0.8.5-4.debian.tar.gz
openarena_0.8.5-4.dsc
  to main/o/openarena/openarena_0.8.5-4.dsc
openarena_0.8.5-4_amd64.deb
  to main/o/openarena/openarena_0.8.5-4_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 592965@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated openarena package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 24 Aug 2010 20:20:07 +0100
Source: openarena
Binary: openarena openarena-server
Architecture: source amd64
Version: 0.8.5-4
Distribution: unstable
Urgency: low
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description: 
 openarena  - fast-paced 3D first-person shooter
 openarena-server - server and game logic for the game OpenArena
Closes: 592965
Changes: 
 openarena (0.8.5-4) unstable; urgency=low
 .
   * Build a second copy of the game logic and install it in a subdirectory.
     It turns out that OpenArena 0.8.1 and 0.8.5 aren't network-compatible.
   * Depend on openarena-data (>= 0.8.5-3~) which causes us to load the
     0.8.1-compatible game logic whenever the upstream version would use
     0.8.1's bytecode (Closes: #592965)
Checksums-Sha1: 
 95df60a1a0124b089a86bf07bb850b5ce6575dfa 2063 openarena_0.8.5-4.dsc
 d97be8e9820266f2221a7e5a31743128def890e8 243071 openarena_0.8.5-4.debian.tar.gz
 89acb208732402ca3730c4e6daa2e115022ab895 927384 openarena_0.8.5-4_amd64.deb
 4aa01b9af4b5738c2204abf6b8e69207d418f0ac 2764274 openarena-server_0.8.5-4_amd64.deb
Checksums-Sha256: 
 6491b60a7281a243ad3c755c4609b750855c636833ef409203a6bd7bf5dd69a7 2063 openarena_0.8.5-4.dsc
 151cd548036ac733f3044fc1d2948308e7938caac3eb3bf24d2e11032c5a8a42 243071 openarena_0.8.5-4.debian.tar.gz
 5928b79cfefaacff678a1bbf9b5d674b9b8abfd9ab8b301363dbb2331aaffdaf 927384 openarena_0.8.5-4_amd64.deb
 971653b7f8183acc814874229b252d8148911b7a7a0ec02a90d84fc908c9562f 2764274 openarena-server_0.8.5-4_amd64.deb
Files: 
 d2bf4b46596504934996b2b2076de2fa 2063 games optional openarena_0.8.5-4.dsc
 f6230102030ffff867c6aa8a74cb8174 243071 games optional openarena_0.8.5-4.debian.tar.gz
 6b52cd8da2cb1c62b29c8a58877b879c 927384 games optional openarena_0.8.5-4_amd64.deb
 32669e4fe7e65cf68ba32b13dea40fff 2764274 games optional openarena-server_0.8.5-4_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIVAwUBTHQim03o/ypjx8yQAQjKYg//RZkvTtxCgCmVRMnUK4joZfmZtMRDvyuy
KoebIS4EBcECpqvVkJ7OuEPRN/ix12UWFx7zXOTdutv2sgsaJgQG54XC84l6Mfcx
TwTrCNyVBAlu+HoBi80W48T3kQQbqovo1DLRhzemPvwKnEEEUv/tDLJtfpvpIjFS
ft8Lsg/uukXsdSYTna0Pl8o6qIugyJAfUdzNLJZBsIUof1tWDWhVoHTMi9Vnh+D3
IjMHJM2GSfJ9siFlV47r9A2vEIes7bePh5o0jdnZKbfalS/rsR3K2q/PIk0lN2nS
ufmv3ZeNjcpxc4fBWfVYwgGmeKWgJ3r0NKunPCnAbEShJgrwG0I+R295bU4LqfDl
MD8N/FryliJBHNNYgFpxA2ltIYFwpvlJnM7ryKFFx/B5KBlQm+XinrRFyELG4YTe
EpAWq6kiI4duAVoAnnHdeTdf1THrRiQpgvTqLXD9zmw+ElQnPuq8YeUXAtsi0lFt
DHM3jE1J4qCx058TcFTXT78k2e2383XXm8z9B4k5DwYWt8sQMkFjkT4XnQefgP1l
/kqWJgEoLnLk3xQE6lx/TmXtfGb5Y0iQ0vtV/FpOhD+j/4IEqld2ZtXiW2wondN3
Aix61ywy1nzScljh/Vu4azr36iWW8ewAShtO4vqU46kkwSIwZepHNPLH4Zi5n+vT
5KRNSGGYKzM=
=HdBK
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.