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

Simon McVittie smcv at debian.org
Sat Aug 21 15:41:56 UTC 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 592965-data.diff
Type: text/x-diff
Size: 4143 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20100821/c6f04c37/attachment-0001.diff>


More information about the Pkg-games-devel mailing list