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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
