Player guide

Builds and versioning

There are no version numbers. Each release replaces the last under the same tag, and a build identifies itself by the date it was compiled.

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-build-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.

Release channels

Three releases are rebuilt in place instead of numbered:

Release	Built from	When
`latest-build`	`master`	Every push to `master` (`build.yml`). This is the one to install.
`latest-beta`	`beta`	Every push to `beta`, marked as a pre-release (`build.yml`). Only when you have been asked to test something.
`winxp`	`master`	Every four months, and when a release is published (`build-winxp.yml`). For Windows XP only.

latest-build and latest-beta carry the same set of archives; the install guide lists which one to download for your system.

Compare the date, not the tag

Each new build deletes the release and creates it again on the new commit, so git describe finds the same tag name every time. The tag part of the identifier reads latest-build on every build and does not tell 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). latest-build is compiled on each push to master, 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"

If your clone has also fetched one of the projects TaystJK descends from, you may see version-like tags such as 1.5.5. They belong to that project, not to TaystJK, and no TaystJK build reports them.

Reporting a build

Paste the whole line; do not summarise 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 instead of 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 the Release builds and the AddressSanitizer build below are 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 24 October 2026 History Edit this page on GitHub