[SOLVED] Run via darkplaces?

I run Debian GNU/Linux primarily, which doesn't ship Xonotic in its repositories. I also find Xonotic to be comparatively harder to compile from source (couldn't find dependency list, makefile was not direct, etc.).

As a free software supporter, I appreciate Xonotic's development, but I honestly can't understand how a developer could live in the Xonotic development environment.

Debian does ship the DarkPlaces engine which can be pointed to a basedir to run Quake-like games such as Xonotic. Even in the source tree, I see a darkplaces directory that gets compiled.

How could I download the Xonotic resources and play the game with darkplaces?

I run Debian GNU/Linux primarily, which doesn't ship Xonotic in its repositories. I also find Xonotic to be comparatively harder to compile from source (couldn't find dependency list, makefile was not direct, etc.).

As a free software supporter, I appreciate Xonotic's development, but I honestly can't understand how a developer could live in the Xonotic development environment.

Debian does ship the DarkPlaces engine which can be pointed to a basedir to run Quake-like games such as Xonotic. Even in the source tree, I see a darkplaces directory that gets compiled.

How could I download the Xonotic resources and play the game with darkplaces?

You can run GIT with these instructions http://dev.xonotic.org/projects/xonotic/...ccess.html or just download the .08 release?

You can run GIT with these instructions http://dev.xonotic.org/projects/xonotic/...ccess.html or just download the .08 release?

This is a pristine example of a situation where someone clearly did not understand the situation at hand. I am a software engineer. I know how to use Git, and I could just download the binary; however, neither of those address the issue I'm dealing with.

I made a single complaint: compiling Xonotic is comparatively difficult (it doesn't follow the GNU build process or really any other standard build process).

My operating system supplies the darkplaces engine in its software repositories, which is my preferred location to download software. I feel more secure downloading from there than from a third-party (from my perspective) site, even if that site is the upstream developer, UNLESS that download is source code/resources.

The question I asked was if there's a way to use the darkplaces engine from the command line to launch Xonotic if I have Xonotic's resources, since compiling Xonotic from source is not a pleasant experience and the underlying engine is already present in my operating system's software repositories.

Please actually read someone's post before ignorantly suggesting they do exactly what they were trying to avoid.

You can run GIT with these instructions http://dev.xonotic.org/projects/xonotic/...ccess.html or just download the .08 release?

This is a pristine example of a situation where someone clearly did not understand the situation at hand. I am a software engineer. I know how to use Git, and I could just download the binary; however, neither of those address the issue I'm dealing with.

I made a single complaint: compiling Xonotic is comparatively difficult (it doesn't follow the GNU build process or really any other standard build process).

My operating system supplies the darkplaces engine in its software repositories, which is my preferred location to download software. I feel more secure downloading from there than from a third-party (from my perspective) site, even if that site is the upstream developer, UNLESS that download is source code/resources.

The question I asked was if there's a way to use the darkplaces engine from the command line to launch Xonotic if I have Xonotic's resources, since compiling Xonotic from source is not a pleasant experience and the underlying engine is already present in my operating system's software repositories.

Please actually read someone's post before ignorantly suggesting they do exactly what they were trying to avoid.

Alrighty then.....

Hello! Thanks for your interesting viewpoint. I have been wondering about this as well, and I'm glad you're raising the issue.

Strictly speaking, Xonotic's resources includes compiled code (gamecode), so it depends on whether you want to compile that yourself or are happy with using the released gamecode.

In the former case, your definition of the "Xonotic resources" boils down to five files:

Code:

font-xolonium-20150113.pk3
xonotic-20150113-data.pk3
xonotic-20150113-maps.pk3
xonotic-20150113-music.pk3
xonotic-20150113-nexcompat.pk3

which you can grab from our rsync server in the following directory: rsync://beta.xonotic.org/release-Xonotic/data/ or simply get them from the release .zip file, as they form the bulk of it anyway.
To run the game using these resource files, you'll have to put them in a directory called "data" and call the darkplaces engine with commandline parameter -xonotic.
You can let the engine know where to look for the data directory either by launching it from the parent directory of data/, or by passing that parent directory with the -gamedir commandline parameter.

I'm assuming above that your engine is compatible with Xonotic 0.8. I'm making this explicit because we're using the branch div0-stable from our git repositories, and I'm not sure the master branch is compatible with Xonotic. If it isn't, the source code for this darkplaces branch, including makefiles, can be taken from our git repos or from the source directory in the Xonotic release (see next paragraph).

If you want to compile the gamecode as well, you'll need to grab the gmqcc compiler from our repos at git.xonotic.org/xonotic/gmqcc.git . Compiling it is a straightforward "make gmqcc".
The gamecode is found in the "source/qcsrc" directory in the xonotic-data pk3 file (which is a zip file). A makefile for this is contained in the source directory. To compile, run:

Code:

make QCC=/path/to/gmqcc qc

. This will compile the three gamecode .dat files (progs, csprogs, menu) in the parent directory to "source".

As for why we're not exclusively using the GNU toolchain, I have no answer to offer. I'll point divVerent to this thread, maybe he'll want to weigh in.

As for our build environment, do you want to expand on why you think it's unpleasant?

(double posted for clarity)

As a GNU+Linux user and developer, I've grown fond of and familiar with the GNU build process using the GNU autotools. However, I'm also very familiar with using cmake.

When I downloaded the source distribution, I noticed a ready-to-go Makefile and gave it a go, only to get a report of "nothing to do" which made no sense to me. In order to compile it, I had to read the makefile itself to see what the build targets were. After that, it failed to build due to a missing dependency. Most software with external build dependencies include instructions in either an INSTALL or a README file with the source distribution so that others building the software will know what other things need to be available on their system in order to build an execute the software.

Really, the build process is up to the developer, but if one were to use a non-standard makefile, they ought to include some instructions on using it. Most of the developers I know don't know how to read a makefile, and certainly a regular user shouldn't have to know. While binary distributions of Xonotic are available, they teach the bad practice of downloading binaries from a third-party. A software repository and package manager (as are commonplace in the Unix world) allows even a clueless user to safely get the software they want and check its integrity. Asking a user to download software from anywhere else in binary form teaches them a practice that could later get them to execute a virus.

As a developer, I'm comfortable downloading source if something isn't available on my repositories, but I almost never download an executable except for a program written in an interpreted language.

As for getting it to work with darkplaces, have you all made modifications to the darkplaces source used for Xonotic? If so, my vanilla engine will surely fail. Otherwise, I'll keep trying. Alternatively, consider submitting a package of Xonotic to be included with Debian?

Mhm, I agree with your points. We should indeed include a readme file with instructions on how to compile the different components.

I think my post above addresses the practical issues you had encountered, namely, the fact that the makefile in source requires the gmqcc compiler and some specific arguments in order to output the compiled gamecode. I forgot to mention also that the gmqcc code is included in the same source directory, so you don't need to get it from git.

As far as I know, and as the name of the branch indicates, historically we didn't use the engine from master as it included features that the Xonotic devs felt weren't stable enough to include in our release. Looking at a full diff between the current state of the two branches, I see there isn't a single difference between the two branches, so you should be fine as long as the engine was built right.

Debian packaging has often come up as a conversation topic in our IRC channels, but I don't know the specifics. Hopefully someone else can tell us more.

Compiling the gamecode yourself won't help much in online play, as the server's client program data (csprogs.dat) is sent to clients, and it uses its own server program (progs.dat).
It won't override menu.dat though, so that may be of use to you.

The vanilla darkplaces engine should still work, might only have a few things missing.
That can be compiled by running make cl-release

Compiling the gamecode yourself won't help much in online play, as the server's client program data (csprogs.dat) is sent to clients, and it uses its own server program (progs.dat).
It won't override menu.dat though, so that may be of use to you.

The vanilla darkplaces engine should still work, might only have a few things missing.
That can be compiled by running make cl-release

There's not a cl-release makefile target with Xonotic. Are you talking about darkplaces? I don't compile that myself since my operating system maintainers have done that for me.

Regarding using another darkplaces build: usually any darkplaces engine built AFTER our Xonotic release will work. We closely track darkplaces svn (sometimes with few recent commits omitted if needed - this is what the div0-stable branch of darkplaces dows). To use another engine, cd to the xonotic root, and run: darkplaces-sdl -xonotic, or create a symlink xonotic-sdl -> darkplaces-sdl and run that (in fact, all we do to our binaries to support xonotic by default is renaming the binaries, as they check argv[0]). Note that only darkplaces builds including most optional dependencies will work for xonotic, and I am not going to be more specific than this as we may use more of them in the future - so if you want this to be reliable, include ALL optional dependencies of darkplaces.

Previous darkplaces builds are explicitly NOT supported, and we ask you to never have xonotic packages depend on a darkplaces version older than what we used. In fact, we will have to actively recommend against using your packages if your darkplaces binary is too old or does not include any dependency we use.

To build the .dat files yourself, run the Makefile from xonotic-data.pk3dir.git. As with darkplaces, your gmqcc sources must not be older than the ones we used and tagged xonotic-v0.8.0 in our repository, as we track master.

As for not using autotools: because darkplaces itself doesn't, and our QC code is built using a single shell command anyway so a pure Makefile is sufficient there.

In case anyone wants to build an autotools based wrapper that builds darkplaces and the QC sources and installs the game, go ahead - patches welcome as long as they can go into xonotic.git itself and don't need to touch the darkplaces repo. To make DarkPlaces itself use autotools, contact LordHavoc.

Regarding using another darkplaces build: usually any darkplaces engine built AFTER our Xonotic release will work. We closely track darkplaces svn (sometimes with few recent commits omitted if needed - this is what the div0-stable branch of darkplaces dows). To use another engine, cd to the xonotic root, and run: darkplaces-sdl -xonotic, or create a symlink xonotic-sdl -> darkplaces-sdl and run that (in fact, all we do to our binaries to support xonotic by default is renaming the binaries, as they check argv[0]). Note that only darkplaces builds including most optional dependencies will work for xonotic, and I am not going to be more specific than this as we may use more of them in the future - so if you want this to be reliable, include ALL optional dependencies of darkplaces.

Previous darkplaces builds are explicitly NOT supported, and we ask you to never have xonotic packages depend on a darkplaces version older than what we used. In fact, we will have to actively recommend against using your packages if your darkplaces binary is too old or does not include any dependency we use.

To build the .dat files yourself, run the Makefile from xonotic-data.pk3dir.git. As with darkplaces, your gmqcc sources must not be older than the ones we used and tagged xonotic-v0.8.0 in our repository, as we track master.

As for not using autotools: because darkplaces itself doesn't, and our QC code is built using a single shell command anyway so a pure Makefile is sufficient there.

In case anyone wants to build an autotools based wrapper that builds darkplaces and the QC sources and installs the game, go ahead - patches welcome as long as they can go into xonotic.git itself and don't need to touch the darkplaces repo. To make DarkPlaces itself use autotools, contact LordHavoc.

Do you think you would be interested in submitting a Xonotic package to Debian? They already package Nexuiz. I think if you'd take an afternoon to read the maintainer's guide, you could get in, which would put Xonotic into half of all the GNU+Linux distributions.

Do you think you would be interested in submitting a Xonotic package to Debian? They already package Nexuiz. I think if you'd take an afternoon to read the maintainer's guide, you could get in, which would put Xonotic into half of all the GNU+Linux distributions.

I plan to put more information about this in the FAQ, but for now, here's the information I have.

The bug report for getting Xonotic into debian repositories with divVerent explanation for the compiling process: https://bugs.debian.org/cgi-bin/bugrepor...bug=646377

A Debian package that's available via playdeb.net: http://www.playdeb.net/updates/ubuntu/14.10/?q=xonotic
(Read the instructions for how to install from playdeb at the top of that page)

Edit: Ultimately we would really love to have Xonotic in the repositories, if anyone can help us achieve this quicker, please contact the team, either here or on IRC.