On Sat, 01 Aug 2009 at 14:20:40 +0100, Simon McVittie wrote: > If you believe that suitable source code for OpenArena game data is not > provided, that would be a bug in openarena-data (a separate source package).
Unfortunately, it appears that this is correct: * openarena-data contains .pk3 files (zip files) * of those, pak0.pk3 contains .qvm files (the "cgame", "game" and "ui" modules), which are bytecode for a VM built in to the Quake 3 engine * the .qvm files are compiled from C in http://www.openarena.ws/svn/source/ using a non-free compiler (lcc) Using gcc (main) ================ It should also possible to compile the cgame, game and ui modules as native code, by copying them into the openarena source package and defining BUILD_GAME_SO. I don't know how portable these modules are (the current packaging dodges that issue by having them as platform-independent bytecode, that was (presumably) compiled on i386), so this may cause build failures on 64-bit or big-endian architectures. This would mean that openarena-data could be made suitable for main by removing the sourceless QVM files - but see below for compatibility. Using lcc (contrib) =================== openarena-data could be made suitable for contrib by working out what the corresponding source code is, providing it in the source package, and requiring that an external q3lcc be used to build it; however, see "Compatibility" below. This would also demote openarena (the binaries) to contrib. (If doing this, it would be convenient if the required version of lcc was uploaded to non-free.) Compatibility ============= Confusing things further, the Quake 3 network protocol checks for compatibility by applying a simple checksum to the PK3 files. The checksum is based on the CRC32s of the unzipped *contents* of the PK3 file, so just unzipping and re-compressing the PK3 file shouldn't be a problem, but recompiling the VMs would be, as far as I can tell - unless Debian has the same "blessed" QVM files that are in upstream's svn, Debian openarena will be incompatible. Since we're building Openarena from source anyway, we control the source code that computes the checksum, so it should be possible to have our Openarena cheat, and claim to other platforms' Openarena builds that its QVMs match the "blessed" upstream ones, even if they actually don't exist. The best way to do this would probably be to include some sort of datafile containing the desired fake checksums in openarena-data, and patch openarena to look for them. The checksums in question are: * normal checksum: a checksum over the CRC32s of the zip file members * pure-server checksum: a checksum over the "checksum feed" (an integer representing the ordered sequence of PK3s the server is using?) followed by the CRC32s of the zip file members so the fake checksum data would have to be a list of CRC32s of zipfile members to pretend to have. The checksumming expects them to be 4-byte little-endian, so the file could just consist of the raw bytes of the CRCs, in LE order. I have some untested code for this if you're interested in this approach. Regards, Simon
signature.asc
Description: Digital signature