Re: Packaging Xonotic
The major blocker here, IMO, is someone who actually *plays* Xonotic,
knows how it works, and is happy to take responsibility for it. I get
the impression that that's not you, and you're mainly packaging it as an
intellectual exercise / "because it's there"? :-)
On 10/11/14 16:22, Markus Koschany wrote:
> The package is very similar to src:nexuiz. It is a simple wrapper around
> the darkplaces engine. I still don't know how d0-blind-id fits in here.
> At the moment it is just a dependency of xonotic.
If you want the feature that it enables, you have to recompile the
darkplaces engine against the d0-blind-id library; there is little (no?)
point in xonotic depending on it.
Exactly what that feature *is* is not particularly clear to me. I think
it's an attempt to give servers an equivalent level of ability to track
player identities, ban troublemakers, etc. that they would have in a
proprietary game with CD-keys, by rate-limiting the registration of new
cryptographic identities at a central server. I'm sceptical about
whether this can possibly work in an open-source game, but hey, it's not
my game.
My understanding is that if d0-blind-id is enabled in darkplaces,
nothing happens, unless the game code actually uses it. Assuming that's
the case, I'd be fine with linking darkplaces to d0-blind-id once it's
in the archive. However, first, someone who knows how Xonotic is meant
to work should do the "whole stack" test.
> * Someone should update d0-blind-id to version 0.7. Maybe even the
> latest version, 1.0, will work.
Whatever works. Ping me if I broke the ACLs on the git repository.
> * We probably have to use upstream's pk3 files to ensure cross-platform
> compatibility. That's how other distributions like Fedora ship the
> data nowadays. However I am almost sure that we can do something
> similar to nexuiz-data and build the pk3 files from source.
If darkplaces does pure-server detection in the same way as ioquake3 (by
checking CRC32sums of the payload inside the zip file, but not doing any
particular validation on the zip file itself), then a possible middle
ground would be to do what I do in OpenArena: ship pre-compiled maps,
pre-compressed textures etc., with their source files alongside in the
source package but no actual automated build step, and zip up the .pk3
at build-time.
S
Reply to: