Builds and versioning

What your build reports

Two commands, and they answer about different halves of the client.

version        the engine
modversion     the game module

version ends with the date the engine was compiled (common.cpp). modversion prints the date and time the game module was compiled, followed by an identifier like latest-6ff04c0ba (CG_ModVersion_f).

Both halves come from the build. GIT_TAG is whatever git describe --tags --abbrev=0 found and GIT_HASH is git rev-parse --short HEAD (CMakeLists.txt). Built outside a Git checkout, both read vUNKNOWN.

Compare the date, not the tag

Releases are rolling: the latest tag is moved onto each release commit, so git describe finds it every time and the tag reads latest on every build. It does not distinguish one release from the next.

The hash does not order builds either. Two short hashes cannot be ranked against each other without the repository. A later hash is not a “higher” one.

So when you want to know whether your build has something, compare the date. The console reference gives each entry an Added date for exactly this purpose; if your build’s compile date is earlier, your build does not have that entry. See how to tell what your build has.

The date is strong evidence, not proof. It is the day the build was compiled, not the day its source was committed (CMakeLists.txt). The latest release is compiled on each push to master (build.yml), so for it the two match. A build compiled later from an older commit, whether the workflow reran or you built an old checkout yourself, carries the later date. An earlier date still proves the entry is missing; a later one only suggests it is there. When that matters, the hash settles it. Each entry’s Added field links the commit that added it, and in a checkout:

git merge-base --is-ancestor <added-commit> <your-build-hash> && echo "your build has it"

The semver-looking tags in the repository (1.0 through 1.5.5 and similar) are inherited from the projects TaystJK descends from. They are not TaystJK releases and no build reports them.

Reporting a build

Paste the whole line rather than summarising it. A useful report says:

• the output of version and modversion, since the engine and the game module are built and shipped separately and can differ
• your operating system and whether the build is 32- or 64-bit, because some features exist only on certain platforms
• which renderer you are running, and whether the problem survives switching to rd-taystjk; see Renderers
• the server and the mod it runs, because much of what you see is the server’s game module rather than the client; see the overview

Every published build is portable

Each artifact the build workflow uploads is built with BuildPortableVersion=ON (build.yml).

A portable build has no home directory at all: Sys_DefaultHomePath returns nothing (sys_win32.cpp, sys_unix.cpp), and fs_homepath then falls back to the install path (files.cpp). Your configs, screenshots, downloaded PK3s and logs are written next to the executable rather than under your user profile. That is what lets you keep TaystJK entirely separate from another Jedi Academy installation, and it is why fs_homepath and fs_basepath read the same in path.

Debug builds are compiled by CI as a check but never archived or uploaded. Only Release is published (build.yml).

The AddressSanitizer build

One extra Windows artifact exists for diagnosing crashes: an x86-64 RelWithDebInfo build with AddressSanitizer enabled, shipped with its PDBs, the sanitizer runtime and a Run-TaystJK-ASan.bat launcher (build.yml).

It is slower than a normal build and it has no Discord Rich Presence: the prebuilt discord-rpc library cannot link against an ASan-annotated binary, so the build forces the option off (CMakeLists.txt).

You want this one only when someone investigating a crash asks for a sanitizer log. Otherwise take the ordinary Release build.

Last changed 28 September 2026 History Edit this page on GitHub