Re: Packaging Xonotic
On 08/11/14 15:20, Markus Koschany wrote:
> I would
> suggest to build a rough version of Xonotic first, solve the most
> important technical issues to make the game run and then optimize the
> packaging as far as this is possible and required. Whether puzzle pieces
> such as d0_blind_id can be replaced by another library should be decided
> later when we have figured out the bigger picture.
I believe we have working packaging for (maybe an old-ish version of)
d0_blind_id which is technically ready for upload; but I don't want to
sponsor its upload until someone can test it in a useful way, which in
practice means having a rough version of Xonotic running. Xonotic does
not have to be perfectly ready for that to happen; for instance, a
version that uses precompiled assets would certainly be fine.
I don't really play multiplayer-only games, so I am not going to
maintain Xonotic, but I'm happy to help with it from the darkplaces
angle. At some point I should probably package the 20140513 upstream
release of darkplaces for experimental - what do Xonotic people think
about that version? Is it good? Is there a nearby svn commit that I
should be using instead, or a set of patches for errata that should be
applied?
> Currently our handling of compiling maps is not consistent and differs
> from game to game. AFAIK Openarena uses pre-compiled maps because
> otherwise it would be impossible to join "pure" servers that require
> pristine maps for anti-cheat measures.
"Pure server" mode was originally an anti-cheat mechanism, but AIUI the
primary reason that the upstream OpenArena programmer is unwilling to
support non-pure servers is less about cheating, and more about network
compatibility. (After all, preventing cheating in an engine with source
available is basically impossible.) OpenArena 0.8.1 is based on code
from the Quake III Arena base game, whereas OpenArena 0.8.5+ is based on
code from the Team Arena addon pack, which is not compatible: in
particular, enums that are used on the network were renumbered, and
structs that are used on the network were rearranged (#592965).
Given that we control the complete source code of all the engines we
ship, it is technically possible to subvert the "pure server" checks as
much as we want, but it can come with a maintenance cost: for instance,
ioquake3 upstream have indicated that they are not willing to merge that
sort of change, so anything we do in that direction is going to be
Debian-specific divergence. As a result, the changes I've applied to
ioquake3 are the absolute minimum to be able to use modified game logic,
and are not a general mechanism for overriding "impurity" in graphics,
maps and so on.
The other thing to think about when deciding between precompiled assets
and compiled-in-Debian assets is that the guidelines we follow for
"code" tend to assume the existence of an automated build system,
because programmers habitually write code to automate anything and
everything; but for maps and other non-code assets, as far as I'm aware,
the "build system" is usually "do a bunch of manual steps in a GUI". The
DFSG says we should package the build system if there is one, but IMO it
does not require us to invent one if there isn't.
Of course, having automated builds for as many of the assets as possible
is a nice thing to have, and a perfectly reasonable feature request for
your upstream; but I don't think its absence prevents those assets from
being included in Debian, as long as they are, or are accompanied by,
the form you would usually modify.
> I have also talked with the upstream
> developers of UFO:AI about that issue and in this case they decided to
> remove the check for pristine maps, so I could build the maps from
> source without making the game unplayable.
If your upstream is willing to do that, great. If not, I don't think
that should be considered to be release-critical.
> I don't
> understand why Xonotic would use a non-free map compiler though.
Because it's there, and/or because the upstream developers don't
consider a complete and self-contained Free toolchain to be as important
as their own content being Free.
Similarly, despite their strict policy of "all assets must be GPL",
upstream OpenArena uses q3lcc, which is non-free (specifically, licensed
for non-commercial use), as its Quake III Arena bytecode compiler. I am
not aware of any DFSG implementations of Quake III Arena bytecode
compilation at all - if I knew of one, I'd use it. Instead, I have a
fairly nasty patch in ioquake3 involving loading native-code equivalents
for the bytecode I can't compile, and using a brute-force process to get
a stub "bytecode" file that happens to have the same CRC32 as the real one.
S
Reply to: