Unfortunately this plan isn't going to work, however it will still be partially implemented, outline of issues and plans are as follows: Upstream developer of UrbanTerror has expressed extreme dislike for this plan, to the point of not wishing it to be included unless it uses ioUrbanTerror (slightly modified ioQuake3). This game has been reverted to using its own engine, because, although it is compatible with ioquake3, there are minor things that do not work as intended. World of Padman has been reverted to using its own modified ioquake3 based engine, to fix issues regarding the master server, and server connection/verification issues. OpenArena has been reverted (well the changes were never committed to SVN, so I simply disregard the old changes I had yet to commit) to using its own modified ioQuake3 engine, due to checksum verification issues of pak0.pk3 (with normal ioQuake3 it tries to validate against the checksum of baseq3's pak0.pk3, which obviously fails and causes the game to exit on joining a pure server). Also, changes to rendering are planned for OpenArena 0.8.0 which ioQuake3 states will not be accepted back into the main engine. Quake 3, will remain using the independently packaged ioQuake3 as baseq3 obviously works perfectly with ioQuake3. ioQuake3 itself will remain packaged and this will allow new mods a way to be quickly packaged (only requiring a launcher script + menu entry + man page), and for the above to be migrated if the issues are ever resolved. Also, ioQuake3 has been patched to compile against Debian's libspeex and libspeexdsp. All these packages are on SVN ready for new inclusion (or upgrade in the case of OpenArena). As a final note, the core issue here is the unreceptive nature of the ioQuake3 team, to new changes. They have refused to accept the auto-downloader tweaks of UrbanTerror, and state they will accept no rendering modifications from any other project. World of Padman and OpenArena could likely work with the shared engine if two minor issues were fixed: Both packages need to set the appropriate sv_master1, and fs_homepath in their default.cfg in their main pk3 (rather than hard coding into their respective engines, although this could be temporarily worked around by setting these cvars in the launcher script). The main issue however is the apparent broken nature of the com_standalone cvar. What I believe this cvar *should* do is as follows: - Disable prompt for CD Key - Disable connection to ID's authorisation/verification server. - Disable checksum verification of pk3's. What it currently seems to do is only disable the reading and writing of fs_homepath/fs_game/q3key. I've spoken to upstream about this and they seem unwilling to change it, preferring that standalone games compile their own engine with the STANDALONE define set. Regards, Jack Coulter
Attachment:
signature.asc
Description: This is a digitally signed message part