Build Requirements
------------------
-Make sure you have at least 2GB memory to compile. This is enough for a git server, but 6GB is required to play using a git client.
+Make sure you have at least 2GB memory to compile. This is enough to run a git dedicated server, but 6GB is required to play using a git client (it uses more memory than regular release and auto builds).
+
+The git client will perform poorly (compared to regular release or auto builds) on GPUs with limited VRAM, such as integrated GPUs.
[About 12GB of disk space is required for the git repositories.](Git)
**Fedora** and other **RPM based** distro dependencies:
- autoconf automake gcc-c++ gmp-devel libjpeg-turbo-devel libtool SDL2-devel curl
+ autoconf automake gcc-c++ gmp-devel libjpeg-turbo-devel libtool SDL2-devel curl libXext-devel alsa-lib-devel libXxf86vm-devel
Note: `x11-proto-devel` or `xorg-x11-proto-devel` might be needed but might be already installed.
Once you have completed the installation, close the current MSYS2 shell and launch a MSYS2 MINGW64 shell by running mingw64.exe (instead of the default msys2.exe) located at C:\msys64 and install the needed dependencies with this command:
- pacman --needed -S git curl zip unzip p7zip make automake autoconf libtool gcc gmp-devel mingw-w64-x86_64-{toolchain,gmp,SDL2,libjpeg-turbo,libpng,libogg}
+ pacman --needed -S git curl zip unzip p7zip make automake autoconf libtool gcc gmp-devel mingw-w64-x86_64-{toolchain,gmp,SDL2,libjpeg-turbo,libpng,libogg,libvorbis}
It is recommended that you make a shortcut to MSYS2 MINGW64 shell (simply right click mingw64.exe and hit “Create Shortcut”) for easier access on your desktop or in your start menu.
Now the game can be compiled and run with the following commands:
- ./all compile -r
+ ./all compile
./all run
-**Note:** if you encounter en error similar to darkplaces#111, try `./all clean && ./all compile -r -0`.
+**Note:** if you encounter en error similar to darkplaces#111, try `./all clean && ./all compile -0`.
-You can use `./all compile -d` to create a slower unoptimized build with debug symbols but usually you want `-r` (which is also the new default).
+You can use `./all compile -d` to create a slower unoptimized build with debug symbols.
-The `./all run` or `./all compile` line can be followed by `dedicated` to build or run the executable for server hosting. E.g. `./all compile -r dedicated`.
+The `./all run` or `./all compile` line can be followed by `dedicated` to build or run the executable for server hosting. E.g. `./all compile dedicated`.
The `run` command can also be followed by standard DarkPlaces commandline arguments:
cd xonotic
./all checkout # switch to main branch on all repos (usually master)
./all update # pull and prune
- ./all compile -r # recompile what changed
+ ./all compile # recompile what changed
**Note:** If you intend to play on public servers, you should probably also enable the nexcompat repo to download additional textures that are used on some older unofficial maps. Use `touch data/xonotic-nexcompat.pk3dir.yes` and `./all update`. For mappers: these textures should NOT be used on new maps.
***
-If you run into issues with the latest version you can easily revert to an older one. Since most bugs are caused by the game code rather that the engine, you just need to downgrade that repository. Inside the main xonotic repository, use `cd data/xonotic-data.pk3dir` and then `git checkout <some older commit>`. After that go back `cd -` and `./all compile` (with the optional `-r` flag).
+If you run into issues with the latest version you can easily revert to an older one. Since most bugs are caused by the game code rather that the engine, you just need to downgrade that repository. Inside the main xonotic repository, use `cd data/xonotic-data.pk3dir` and then `git checkout <some older commit>`. After that go back `cd -` and `./all compile`.
Contributing and Getting Write Access
-------------------------------------
-Cloning (one of) our repos and submitting MRs from there (as in any other project) works but you won't be able to use our CI setup for the data repo (which seems to need a custom runner). It's therefore a good idea to join the Xonotic group and get push access - then you can create branches in our repos and use our CI.
+It's recommended to [request access](https://docs.gitlab.com/ee/user/group/index.html#request-access-to-a-group) to the [Xonotic project group](https://gitlab.com/xonotic). Cloning our repositories and submitting merge requests from there will work but you won't be able to use our CI setup for the xonotic-data.pk3dir repo (which seems to need a custom runner).
-A condition for write (push) access is that you agree that any code or data you push will be licensed under the General Public License, version 2, with or without the “or any later version” clause. In case the directory the changes apply to contains a LICENSE or COPYING file indicating another license, then your pushed code has to be dual licensed appropriately. Subdirectories currently having a dual license:
+A condition for write (push) access and submission of merge requests is that **you agree that any code or data you push will be licensed under the [GNU General Public License, version 2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html), with and/or without the “or any later version” clause.**
-* `data/xonotic-data.pk3dir/qcsrc/lib/warpzone` - dual licensed as “GPLv2 or later” or MIT license.
+If the directory or repository your changes apply to contains a LICENSE or COPYING file indicating another license or a dual license, then **you agree that your pushed code will be licensed as specified in that file.** Subdirectories and repositories with a dual license or a different license:
+* [xonotic-data.pk3dir/qcsrc/lib/warpzone](https://gitlab.com/xonotic/xonotic-data.pk3dir/-/tree/master/qcsrc/lib/warpzone) - dual licensed with GNU GPLv2 (or any later version), or MIT license.
+* [xonstat-go](https://gitlab.com/xonotic/xonstat-go/) - licensed with [GNU AGPLv3](https://www.gnu.org/licenses/agpl-3.0.html)
In case the code you pushed was not written by you, it is your responsibility to ensure proper licensing.
-To apply for write access, add your SSH key to your GitLab account and ask for access in #xonotic on the FreeNode IRC network or [request access](https://docs.gitlab.com/ce/user/group/index.html#request-access-to-a-group) using the GitLab interface.
+To apply for write access, please add your SSH key to your GitLab account and [request access](https://docs.gitlab.com/ce/user/group/index.html#request-access-to-a-group) to the [Xonotic project group](https://gitlab.com/xonotic) using the GitLab interface. You can also request access on Matrix chat in [#dev:xonotic.org](https://matrix.to/#/#dev:xonotic.org) (remember to tell us your GitLab username!) but the admins might not see your request amongst the other messages.
+
+Please read [General Contributor Guidelines](https://gitlab.com/xonotic/xonotic/-/wikis/Repository_Access#general-contributor-guidelines) before pushing.
### Windows/Linux/macOS
------------------------------
1. Before creating your local branch and committing to it, make sure you’ve configured your user settings such as your name which will display in the logs (in TortoiseGit: Settings > Git > Config).
-2. You should name your branch myname/mychange for each patch. For instance, if your name is Alex and the change you are committing is a menu fix, use something like alex/menufix.
+2. **You should name your branch myname/mychange for each patch.** For instance, if your name is Alex and the change you are committing is a menu fix, use something like alex/menufix.
Git guides
-----------------------
projects / xonotic / xonotic.wiki.git / blobdiff