You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix: The AppImage drew its loading bar and then aborted with "CEGUI::RendererException ... STBImageCodec - stb_image.c based image codec failed to load image 'darkening.png'". That file was a 1-BIT COLORMAP PNG. It had always been one, and it had always worked - under DevIL. Switching CEGUI to its built-in STB image codec, so the macOS and Windows builds would link, quietly took away support for sub-8-bit PNG depths: CEGUI 0.8 vendors an old stb_image.c that decodes 8 and 16 bits only. Five files out of 1029 were affected - darkening.png and the four screw_block middle textures - and the first one the GUI touched killed the process. All five are converted to 8-bit RGBA, which is lossless for a palette of two colours and works with any codec rather than only the one that happens to be linked. (by Lauri Ojansivu)
Misc: New test testing/png-bit-depth-test.sh, run by tsc/testing/run-tests.sh, fails on any PNG in the game data below 8 bits per channel. Nothing caught the bug above at build time: the data is copied rather than decoded, so the build succeeded, and "tsc --print-paths" confirms the data is FINDABLE - the PREVIOUS bug - while saying nothing about whether it DECODES. It only appeared when one particular image was loaded, at runtime, on a machine with a display. The test reads the bit depth straight out of each PNG's IHDR with od, so it needs no image library, no file and no Python; it names the offending files and prints the exact conversion command; and it fails when it finds NO PNGs at all, because a check that checked nothing must not report success. Verified in both directions - it passes on the converted data and fails on all five originals. (by Lauri Ojansivu)
Fix: The macOS disk image was missing from the release for two reasons, one behind the other. With -Wl,--as-needed no longer refused by Apple's linker, all three macOS jobs reached the link and ended there instead: "_libintl_ngettext", "_libintl_setlocale" and "_libintl_textdomain" undefined, "ld: symbol(s) not found for architecture arm64", on macOS 15 arm64, macOS 15 x86_64 and macOS 26 arm64 alike. On Linux the gettext functions are IN glibc, so nothing has to be linked and nobody notices; on macOS they are not in libSystem. CMakeLists.txt resolved and linked iconv and intl on WIN32 and on the BSDs, and macOS fell into the plain else-branch and linked neither - it now uses the same find_package branch as the BSDs. That alone still failed, because Homebrew's gettext is KEG-ONLY: macOS ships a BSD gettext of its own, so Homebrew refuses to shadow it and brew install gettext does not symlink libintl into $(brew --prefix)/lib, which was the only prefix on CMAKE_PREFIX_PATH. find_library(intl) came back empty for a library installed the whole time, in a directory nothing was looking in. Mac.yml passes the keg's own prefix too, and CMakeLists asks brew --prefix gettext itself so a plain local cmake finds it as well. New test testing/macos-libintl-test.sh, run by tsc/testing/run-tests.sh, reads both files and then REPRODUCES the bug on any OS: it builds a libintl that exists but sits on no default search path, shows find_package(LibIntl REQUIRED) failing without its prefix, then finding it and linking with it. (by Lauri Ojansivu)
Fix: 26 CEGUI::RendererException lines while the game ran, and a dummy image drawn for each. Not the bit depth this time: png-bit-depth-test.sh passed 1029 of 1029 while every one of these was broken, and each failing file is 8-bit and non-interlaced. What they have in common is their COLOUR TYPE, 0 (greyscale) or 4 (greyscale+alpha) - 38 of the 1029 PNGs are one of those two, and the 26 in the log are the ones that session happened to open. CEGUI's STBImageCodec asks stb for whatever channel count the file has, with stbi_load_from_memory(..., &comp, 0), and then accepts only comp 3 and 4; greyscale is ONE channel and greyscale+alpha TWO, so stb decoded them perfectly well and the switch threw them away with "Only RGB and RGBA images are supported". The new cegui-stb-greyscale.patch, applied by ProvideCEGUI.cmake beside the two patches already there, reloads those two cases asking for RGBA - the same decoder doing the widening the caller would otherwise do, since stb's convert_format has CASE(1,4), which fills an opaque alpha, and CASE(2,4), which keeps the image's own. 3- and 4-channel images are untouched, so the 962 that already worked load exactly as before. Converting the 38 files would also have worked and would have been wrong: it fixes those 38 and nothing else, leaving a greyscale PNG in somebody else's level still drawing a dummy image. Verified against the real assets rather than by reading - compiling the codec's exact logic against CEGUI's own vendored stb_image.cpp and running it over the game data gives 38 rejected before and 0 after, and over the 26 files named in the log, 26 before and 0 after. New test testing/cegui-greyscale-test.sh. (by Lauri Ojansivu)
Fix: An ordinary start reported two problems it does not have. Every first run printed "Warning: Preferences file ... does not exist. Using default values." on stderr - there is no preferences file until something is saved, so the first thing a new player saw was the game reporting a fault it did not have. It is a fact on stdout now and still names the path, so an EXISTING preferences file that stopped being found is as visible as before. And "No joysticks available" printed on almost every start, because most machines have no joystick, while its own sibling "Joysticks found : N" was already behind m_debug - the uninteresting answer loud, the interesting one silent. Both are gated now. This is not only tidiness: the 26 image errors above sat in exactly this noise. New test testing/startup-messages-test.sh. (by Lauri Ojansivu)
Fix: A release workflow could be stopped from LOADING by its own only input. Each of AppImage.yml, Deb.yml, Flatpak.yml, Mac.yml and Windows.yml decided which matrix entries to build with a template expression on the build job, contains(fromJSON(inputs.only), matrix.arch), and fromJSON there is evaluated while the workflow TEMPLATE is parsed. A value that is not JSON therefore did not fail a build, it failed the run: dispatching AppImage with only: v2.2.0-beta2 answered "The template is not valid. .github/workflows/ AppImage.yml (Line: 148, Col: 19): Unexpected character encountered while parsing value: v", all three architectures died at "Prepare workflow directory" before a single step ran, and the publish job then reported "No architecture produced an AppImage - every build job failed" while their logs were empty. The question is answered in a shell now, by the new .github/scripts/matrix-only.sh, which the "read the version" job of each workflow runs: it accepts ["a","b"], a,b or a b, rejects anything else with a message naming that workflow's valid entries, and always prints valid JSON - so the fromJSON in the build job can no longer throw. The only input's description now lists the entries it accepts, the tag and only inputs reach the shell through the environment instead of being interpolated into a command line, and the "nothing was built" error points at the version job as well as at the build logs. (by Lauri Ojansivu)
Fix: A release tag is no longer pasted into a shell line. Seven steps across Deb.yml, Flatpak.yml, Mac.yml, Windows.yml, Repos.yml, release-all.yml and release-all-missing.yml began with tag='${{ inputs.tag }}', which puts a value somebody typed into a dispatch box inside a single-quoted shell string: a quote in the value ends the string and the rest of it becomes script. All seven read the value from the environment now, where the shell never parses it, and so do the three steps of AppImage.yml's publish job that carry the same value one hop later as needs.version.outputs.tag. This is the same class as the only input above - a hand-typed value reaching somewhere that treats it as syntax - and testing/matrix-only-test.sh now fails if any workflow puts one back. (by Lauri Ojansivu)
Fix: The AppImage packaging script could fail a release for a reason that is not the AppImage's. After packing, it unpacks what it built and runs tsc --print-paths to prove the game finds its data; anything that stopped that check from RUNNING - no unsquashfs, an image that would not unpack, no tsc inside it - failed the build and withheld a finished AppImage. Those three warn now. The one case that still fails the build is tsc itself saying the data is not where it will look for it, which is the bug the check is there for. testing/build-appimage-test.sh pins both halves. (by Lauri Ojansivu)
Misc: The release scripts' Python bytecode is ignored. Running .github/scripts/expected-assets.sh or any other release helper leaves pycache directories and .pyc files beside the scripts, which then show up in git status and invite being committed - build output for one machine's interpreter version, useless to everybody else. .gitignore covers them now. (by Lauri Ojansivu)
Misc: New standalone tests, in tsc/testing, run by tsc/testing/run-tests.sh. They need only a C++ compiler and a shell - no SFML, no CEGUI, no boost, no display and no installed game - so both ./build-tsc.sh and the packaging jobs in .github/scripts/build-tsc.sh run them before compiling anything. There are three. data_dir_test.cpp drives the game data directory decision against a fake directory tree and pins the AppImage case, the installed case, the relocated cases, and that an empty $TSC_DATA_DIR or a stale $APPDIR is ignored rather than used as a path. testing/matrix-only-test.sh pins what the workflows' only input accepts and refuses, that no workflow hands a raw input to fromJSON any more, and that every selector .github/scripts/expected-assets.sh can produce is one its workflow accepts - so "Release all missing" cannot ask for an asset with a selector the workflow would now reject. And testing/build-appimage-test.sh pins what the AppImage packaging script may and may not fail a release for. (by Lauri Ojansivu)
Fix: The AppImage started and then aborted before drawing anything, with "CEGUI::FileIOException ... /usr/share/tsc/gui/schemes/TSCLook256.scheme does not exist". It carried all of its game data, but looked for it at the path compiled in at build time - /usr/share/tsc - and an AppImage is never installed there: its /usr tree is mounted under /tmp/.mount_TSCxxxxxx when it runs, so the compiled-in path belongs to some other TSC or to nothing at all. On Unix the game data directory is now decided by Determine_Game_Data_Dir() in src/core/filesystem/data_dir.cpp, which takes the first of $TSC_DATA_DIR, $APPDIR plus the compiled-in path (the AppImage runtime exports $APPDIR), the running executable's own location from /proc/self/exe with "../share/tsc" applied, and finally the compiled-in path itself, which is still the answer for an installed package. The executable's location is consulted BEFORE the compiled-in path so that a machine with a system TSC installed does not have that other version's data loaded into the AppImage. This also fixes every other relocated build: an unpacked --appimage-extract tree, a tarball, and the developer build from ./build-tsc.sh, which installs into a relative prefix and until now only found its data when started from the right working directory. (by Lauri Ojansivu)
Misc: New option "tsc --print-paths" prints the game data directory, the user data directory and the preferences file, and exits nonzero when the game data is not where TSC will look for it. It opens no window and touches no OpenGL, so it answers "why does it not start" over ssh and in a container - and .github/scripts/build-appimage.sh now runs it against the AppImage it just packed, unpacked so the check works on the emulated armhf job too, and refuses to publish one that cannot find its own game data. (by Lauri Ojansivu)
Fix: The macOS build failed to compile src/core/collision.cpp with "no template named 'binary_function'" and "no member named 'bind2nd'". Both std::binary_function and std::bind2nd were deprecated in C++11 and removed in C++17, which TSC uses for SFML 3; libstdc++ still provided them so Linux built, but macOS's libc++ does not. The four collision predicates (Is_Included and Find_First over sprite, array type, sprite type and validation type) are lambdas now, capturing what bind2nd used to bind as the second argument - the same comparison, no removed API. (by Lauri Ojansivu)
Misc: "Release all" and "Release all missing" now update the website's download pages for the release they build. A new script, .github/scripts/update-download-pages.py, reads the release's assets and its .md5sum/.sha256sum files and rewrites the Beta Version tables on the en/es/fi download pages of Secretchronicles/secretchronicles.github.io - every package's download link and its md5 and sha256 - so the page stops advertising an old beta the moment a new one is built. Repos.yml does it in the same commit that publishes the apt/AppImage/Flatpak repositories, from the same release, so the page that offers a download and the repository that serves it cannot drift apart; the section lives between HTML markers so each run is a clean replacement. Needs the WEBSITE_TOKEN secret, as the repo push already did. (by Lauri Ojansivu)
Fix: "Release all" and "Release all missing" now add the checksums that some assets had none of. Each build workflow named its checksum files with the extension dropped - TSC--x86_64.AppImage was checksummed as TSC--x86_64.md5sum - so two assets that share a stem wrote to one name and whichever ran second overwrote the first: the x86_64 and aarch64 AppImages lost theirs to the same-arch Flatpak, and the win64 .exe to the win64 .7z, which is why those three had no md5 or sha256 on the v2.2.0-beta2 release. The checksum files keep the full asset name now (TSC--x86_64.AppImage.md5sum), so every asset gets its own pair; expected-assets.sh and release-all-missing.yml look for the new names, so a re-run over that release fills in the missing checksums. (by Lauri Ojansivu)
Fix: Every macOS build still failed with "no template named 'auto_ptr' in namespace 'std'", although the std::auto_ptr shim added for exactly that was force-included in the very command that failed. The shim's guard was #if defined(_LIBCPP_VERSION), tested BEFORE it included any standard header - and _LIBCPP_VERSION is defined by libc++'s <__config>, which nothing had pulled in yet, because a force-included file is the first thing the compiler sees. The macro was therefore always undefined, the shim compiled to nothing, and libxml++ 2.6's std::auto_ptr<Impl> pimpl_; members broke every translation unit that includes a libxml++ header - and with xmlpp::SaxParser ill-formed, the classes deriving from it (cCampaignLoader, cLevelLoader, the overworld loaders) failed after it. The header now includes first and then tests libc++ + C++17 + the absence of _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR, so it defines auto_ptr exactly when the standard library has none; and if it ever ends up inert on macOS again it says so itself with a #warning naming the reason, instead of leaving a wall of errors that mention neither the shim nor libxml++. (by Lauri Ojansivu)
Fix: The 64-bit Windows installer could never be packaged: the build succeeded and CPack then died with "CMake Error at cmake_install.cmake:57 (get_filename_component): called with incorrect number of arguments", so neither the NSIS installer nor the 7z archive was produced and the release job had nothing to attach. The Windows install(CODE) block appends CEGUI's CoreWindowRendererSet to the prerequisite list by name, because it is loaded at runtime and GetPrerequisites cannot see it, and it took that name from CEGUI_CoreWindowRendererSet_LIBRARY - which only FindCEGUI.cmake sets, i.e. only when CEGUI is found on the system. Windows builds CEGUI here instead (ProvideCEGUI.cmake, USE_SYSTEM_CEGUI defaults to OFF), so the variable was empty and, expanded at configure time into the generated install script, left get_filename_component(VAR NAME) - two arguments where three are required. The name is resolved at configure time now, where it can be tested, and nothing is appended when there is nothing to append: with the static CEGUI the Windows build uses, the window-renderer set is already linked into tsc.exe. (by Lauri Ojansivu)
Fix: The macOS "attach to the release" job could never publish a disk image, whether or not one had been built. Its "Collect the disk images" step ends with a warning whose closing quote was missing, and bash - which parses a script one command at a time - ran everything before it and then hit EOF inside the unterminated string: "unexpected EOF while looking for matching \"'", exit 2, after the images had been collected and with nothing else wrong. The same step also ran find partsbefore checking thatpartsexists; when every build job fails, download-artifact creates no such directory,findexits non-zero andset -e` ended the step on a bare "find: 'parts': No such file or directory" - hiding the "No macOS disk image was produced at all" message the step already had ready for exactly that case. The quote is closed and the directory is created empty first, so a good run publishes and a failed one says why. (by Lauri Ojansivu)
Change: The 32-bit Windows (win32) build is built against a WeKan-maintained MSYS2 mirror instead of failing on MSYS2's dropped packages. MSYS2 ended 32-bit support in May 2024 and delisted every i686 library (sfml, boost, glew, freetype, libxml++, ...) from mingw32.db, so pacman -S mingw-w64-i686-sfml reported "target not found" and win32 could not build - only the toolchain (gcc, cmake, ninja, pkgconf) is still listed. The files are still served, just delisted, so they are mirrored with a regenerated database; libxml++ 2.6, which MSYS2 no longer builds at all (its libxmlpp is now 5.x), is rebuilt for i686 from its PKGBUILD; and the win32 job installs the toolchain from the live mingw32 db and every library from the mirror, whose pacman Server URL is the repository/organization variable MINGW32_MIRROR. The mirror and package tooling live in the wekan repo's log/ directory (mirror-mingw.sh, build-mingw32-package.sh, regenerate-mirror-db.sh, upload-msys2-mirror-to-github.sh, generate-msys2-mirror-site.sh). win32 stays expected_to_fail until MINGW32_MIRROR is configured. (by Lauri Ojansivu)
Fix: The Windows (win64) build failed at link with "undefined reference to `__imp__ZN5CEGUI...'" for String, System, OpenGLRendererBase, Exception and friends. CEGUI is built as STATIC libraries, but the static ProvideCEGUI path never defined CEGUI_STATIC, so on Windows the CEGUI headers declared every symbol __declspec(dllimport) - an _imp* import the static libs do not provide - and MinGW's ld could not resolve them. It now defines -DCEGUI_STATIC in the static-CEGUI branch (a no-op where there is no dllimport, Linux and macOS). This surfaced only now because CEGUI itself finally builds after the DevIL->STB switch. (by Lauri Ojansivu)
Fix: The macOS build failed compiling every unit that includes a libxml++ header with "no template named 'auto_ptr' in namespace 'std'". TSC is -std=c++17 (for SFML 3), which removed std::auto_ptr, and macOS's libc++ does not provide it under C++17 - from libc++ 18 not even behind the opt-in _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR macro - yet libxml++ 2.6, the only libxml++ Homebrew ships (2.42.x; there is no 3.0/5.0 formula), still declares std::auto_ptr members. A tiny libc++-only std::auto_ptr shim (src/core/libxmlpp_autoptr_compat.hpp), force-included on macOS, restores it; Linux's libstdc++ keeps auto_ptr, so the shim is libc++-guarded and never redefines an existing one. (by Lauri Ojansivu)
Fix: The Flatpak "attach to the release" job failed at "Upload the bundles" with "read assets/objects: is a directory". Its download-artifact pattern (flatpak-[0-9a-z], merge-multiple) also matched the flatpak-repo- artifacts, so assets/ held the ostree repo layout (objects/, refs/, ...) as well as the .flatpak bundles, and gh release upload assets/* then tried to upload the objects directory. It now uploads only assets/.flatpak and their checksums; the repository is published separately, to GitHub Pages, not to the release. (by Lauri Ojansivu)
Fix: CEGUI now uses its built-in STB image codec instead of DevIL, which never linked on macOS or Windows. CEGUI is built statically, and its DevIL finder then demands a STATIC libIL archive (IL_LIB_STATIC); Homebrew and MSYS2 ship only a shared libIL, so it reported "Could NOT find IL (missing: IL_LIB_STATIC ...)" and the codec never built - and unlike GLEW, its finder rejects the shared library offered as the static one. TSC only decodes PNG imagesets, so it switched to CEGUI's STB codec (stb_image, a vendored header with no external library to find on any platform). DevIL, find_package(DevIL) and libIL are gone. (by Lauri Ojansivu)
Fix: The Flatpak build failed linking SFML's audio - undefined reference to ov_pcm_seek (vorbisfile) and FLAC__stream_decoder_* (FLAC). SFML's cmake found Vorbis and FLAC in the freedesktop SDK but built a STATIC libsfml-audio-s.a, and a static library carries none of its dependencies, so when TSC links it the FLAC/Vorbis/Ogg symbols are unresolved. Every other platform links a shared SFML (apt, Homebrew, MSYS2) whose .so pulls them in; only the Flatpak builds SFML from source and it went static. -DBUILD_SHARED_LIBS=ON makes the Flatpak's SFML shared like the rest. (by Lauri Ojansivu)
Fix: The CEGUI DevIL image codec still failed to link on macOS and Windows after the earlier DevIL hint - _ilInit / __imp_ilInit undefined. The hint set IL_LIB, but CEGUI is built with its STATIC configuration, whose DevIL finder wants the STATIC library variables and reported "Could NOT find IL (missing: IL_LIB_STATIC IL_LIB_STATIC_DBG)" - so the codec never linked libIL. Those variants, and the ILU ones, are passed now too, pointing at the same shared libIL the finder resolved (DevIL has no static archive on these platforms); CEGUI only needs them set, exactly as its GLEW finder needed GLEW_LIB_STATIC. (by Lauri Ojansivu)
Fix: The release notes on GitHub no longer freeze at what CHANGELOG said when the release was first created. They are read from this file, but were written only when the release did not exist yet or had an empty body, so a later CHANGELOG edit never reached the release page - and both "Release all" re-runs and "Release all missing" complete an already-created release. Every run re-copies the entry for the version now, comparing against the current body first so the parallel build workflows do not each rewrite an unchanged one. (by Lauri Ojansivu)
Fix: CEGUI's own build could not find GLEW and stopped with "Building the old OpenGL renderer module is only supported using GLEW", on Windows first and then on the Flatpak runtime. CEGUI is a separate cmake run with its own bundled GLEW finder, which looks for a library named GLEW or glew and so misses MSYS2's glew32, and missed it on Flatpak too even though the outer find_package(GLEW) had found it. GLEW is resolved once and handed to CEGUI's GLEW_LIB/GLEW_H_PATH cache variables now, on every platform rather than only on Windows. (by Lauri Ojansivu)
Fix: Every macOS and 64-bit Windows build died linking CEGUI's DevIL image codec, with undefined _ilInit / __imp_ilInit: the codec compiled but no libIL was on the link line. Forwarding CMAKE_PREFIX_PATH to the sub-build found DevIL's HEADERS but not its library, which was not enough. DevIL is now resolved the same way GLEW is and handed to CEGUI's IL_LIB/IL_H_PATH (and ILU_LIB) cache variables, so the codec links the library it was compiled against. (by Lauri Ojansivu)
Fix: The Flatpak build failed compiling the shared-modules udev-175 module - "implicit declaration of function 'major'/'minor'". udev 175 predates glibc moving major()/minor() into <sys/sysmacros.h>, so it no longer compiles, and upstream flathub shared-modules has deleted it. SFML needs libudev for joystick input; the manifest defines an inline eudev 3.2.14 module - the maintained standalone libudev - from a pinned release with its checksum verified, in place of the udev-175 reference. (by Lauri Ojansivu)
Fix: The armhf AppImage failed after TSC had already built. linuxdeploy and appimagetool ship their armhf builds as static-PIE AppImages, and qemu-user - which runs the armhf binaries on the x86_64 runner this job emulates on - cannot load a static-PIE executable, so the tool never started. build-appimage.sh unpacks each tool's appended squashfs and runs the dynamic binary inside instead, which qemu-user can run. Finding that squashfs by the first 'hsqs' magic in the file was not enough, because that four-byte sequence also occurs in the ELF runtime ahead of the real squashfs and unsquashfs then died with "Can't find a valid SQUASHFS superblock"; it tries every candidate offset now and keeps the one that unsquashes into a tree with an AppRun. (by Lauri Ojansivu)
Fix: The build failed to link on FreeBSD with "ld: error: unable to find library -liconv". iconv and intl were named as bare linker flags, which asks the linker to find them on its default search path, and the BSD ports tree puts them under /usr/local/lib, which is not on it. They are resolved to full paths by find_package now, the way every other dependency in the file already was. (#693 by Lauri Ojansivu)
Fix: Taking a screenshot crashed the game. The buffer was sized from the resolution TSC was configured for while glReadPixels filled it from the framebuffer TSC actually had, and OpenGL pads every row of an RGB image out to a multiple of 4 bytes unless it is told not to - either one writes past the end of the buffer, which is the "free(): invalid next size (normal)" abort in the report. cVideo::Get_Pixel had the same padding bug in its worst form: a 3-byte buffer for a row OpenGL rounds up to 4. (#723 by Lauri Ojansivu)
Fix: Losing a life reset the score to 0. The points are what the whole playthrough has earned and they carry across lives, as they do in the games this one is shaped like; a single death threw all of them away. The score still goes back to zero when a playthrough ends and a new one starts. (#707 by Lauri Ojansivu)
Fix: The .deb packages were missing their DevIL dependency, so tsc would not start - "libIL.so.1: cannot open shared object file" - until libdevil1c2 was installed by hand. The Depends line was written out by hand and DevIL was left off it; Deb.yml reads the dependency list off the compiled binary with dpkg-shlibdeps instead, so a library TSC links against cannot be missing from it. (#724 by Lauri Ojansivu)
Misc: Added GitHub workflow AppImage.yml, which builds an AppImage for each CPU architecture AppImage has a runtime for (x86_64, aarch64, armhf) and attaches them to the release this file names. An AppImage runs on any Linux distribution without being installed, which matters more than usual now that TSC needs SFML 3: only Ubuntu 26.04 and Debian 14 ship it, so on anything older there can be no TSC package at all, while the AppImage carries its own SFML and runs from Debian 12 onwards. (by Lauri Ojansivu)
Misc: Added GitHub workflow Deb.yml, which builds a .deb for each CPU architecture it can be built for - amd64, arm64, armhf, ppc64el, s390x and riscv64 - on Ubuntu 26.04 and Debian 14, and attaches them to the newest release. The v2.2.0-beta1 packages were built by hand, one machine per distribution and architecture, with the Depends line of each typed out; these are built from one commit in one run, with the dependency list read off the compiled binary by dpkg-shlibdeps. (by Lauri Ojansivu)
Misc: Added GitHub workflow Windows.yml, which builds the 64-bit Windows installer with MSYS2 UCRT64 and CPack's NSIS generator. This also answers #709 ("cegui dependency not available for building Windows version") by what it does NOT install: TSC has compiled CEGUI itself from its submodule since 2024-10-04, so the MSYS2 cegui package INSTALL.md still asks for is not needed and no longer exists. The 32-bit job is kept and expected to fail: MSYS2 ended 32-bit support in May 2024, months before SFML 3 was released, so there is no 32-bit SFML 3 to build against. (#709, #719 by Lauri Ojansivu)
Misc: Added GitHub workflow Mac.yml, which builds macOS 13, 14 and 15 disk images on Intel and Apple silicon and welds the two CPUs into one universal disk image with lipo, so there is a single file that runs on both. Only that universal image is published: shipping the per-CPU images beside it would be three downloads where one will do, and three chances to take the wrong one. It replaces the hand-made zip on a file-sharing site that #691 offered with a build anyone can re-run from a commit. (#691, #719 by Lauri Ojansivu)
Misc: Added GitHub workflow Flatpak.yml, which builds Flatpaks for x86_64 and aarch64, attaches the single-file bundles to the release, and publishes a multi-architecture Flatpak REPOSITORY of static files that the website can serve, so flatpak update works rather than every update being a download by hand. (#733, #719 by Lauri Ojansivu)
Dependencies: Brought the Flatpak manifest back to life. It was written in 2018 against runtime 18.08 and had rotted: boost came from bintray, shut down in 2021, and SFML was 2.5.1, which the SFML 3 port no longer builds against. It is on freedesktop 24.08 with a live boost URL and SFML 3.0.2 now, and its cegui and mruby modules are gone - TSC compiles both itself, so building them into /app built something nothing used. (by Lauri Ojansivu)
Fix: GLEW was found and then reported missing, stopping the build on Debian 14, macOS and Windows while Ubuntu 26.04 built fine. GLEW 2.3 ships a CMake CONFIG package and 2.2 does not: where the config package wins, cmake says "Found GLEW: .../glew-config.cmake" and exports the targets GLEW::glew and GLEW::glew_s WITHOUT setting the module variables, so ${GLEW_LIBRARIES} carried GLEW_LIBRARY-NOTFOUND into the generate step. ProvideCEGUI.cmake asks for a target first and falls back to the variable. (by Lauri Ojansivu)
Fix: The Flatpak build stopped on "module boost: Failed to execute child process eu-strip". flatpak-builder strips debug info out of every module it builds and does not pull in elfutils, which provides eu-strip; the workflow installs it. (by Lauri Ojansivu)
Fix: The armhf .deb died measuring itself - "du: cannot read directory: Value too large for defined data type", EOVERFLOW from a 32-bit process meeting a 64-bit inode number under emulation. Installed-Size is informational and dpkg-deb builds a good package without it, so a package that cannot be measured is still shipped rather than failing. (by Lauri Ojansivu)
Fix: The first release-all run failed on every platform, on five separate causes, none of which had reached a compiler. cmake stopped at the first line of tsc/CMakeLists.txt on Windows, macOS and Ubuntu 26.04: CMake 4 removed compatibility with cmake_minimum_required below 3.5, and it asked for 3.0. It asks for 3.5 now, the same value ProvideCEGUI.cmake already forces on CEGUI. (by Lauri Ojansivu)
Fix: The container builds - every .deb and every AppImage - died on "detected dubious ownership in repository at '/src'". The container runs as root and the checkout belongs to the runner user, so git refused every command, including the submodule update that fetches CEGUI and mruby. The mounted repository is marked safe. (by Lauri Ojansivu)
Fix: flatpak-builder rejected the manifest outright: "No slashes allowed in dest-filename, use dest property". The COPYING source had dest-filename "tsc/COPYING", which is a path and not a file name; it is dest "tsc" plus dest-filename "COPYING" now. (by Lauri Ojansivu)
Fix: The macOS runner labels had moved. macos-13, which this used for the Intel build, has been retired outright, and macos-14 is deprecated. Intel is macos-15-intel now, and macos-15 on its own is Apple silicon, so the matrix is macos-15 and macos-26 for arm64 and macos-15-intel for x86_64 - which keeps the universal disk image possible. (by Lauri Ojansivu)
Fix: The repositories job stopped with a bare exit code 2 on a release with no packages yet. Counting them with ls *.deb | wc -l under set -e and pipefail makes the glob matching nothing a fatal error, and an empty release is exactly the case that loop exists to report. It counts with nullglob and an array, and says which package type is missing. (by Lauri Ojansivu)
Fix: The run summary could not read the release: it has no checkout, and gh works out the repository from the git remote, so it failed with "not a git repository". It names the repository explicitly. (by Lauri Ojansivu)
Fix: The Windows build produced nothing. mruby was built by running ./minirake, which is a Ruby script with no extension: its shebang makes that work on Linux and macOS, which is why it was never noticed, but cmd has no shebangs and answered "'.\minirake' is not recognized as an internal or external command". ninja stopped there, so the release got no Windows installer at all. It is run through the interpreter find_package(Ruby) already located. (by Lauri Ojansivu)
Fix: Every macOS build failed to link. Mac.yml configures TSC with -DCMAKE_OSX_ARCHITECTURES, but an ExternalProject is a separate cmake run and inherits only what CMAKE_ARGS names, so CEGUI never saw it, defaulted to x86_64 and linked against the arm64 Homebrew libraries beside it. The giveaway is that the error says x86_64 in the two arm64 jobs as well. The architecture, deployment target and sysroot are forwarded now, on Apple and only when set. (by Lauri Ojansivu)
Fix: Both Flatpak builds failed in glu, whose 9.0.0 source uses NULL without including stddef.h and does not compile with the runtime's GCC. glu is 9.0.3 now, taken from what flathub shared-modules uses today, with its checksum verified against the downloaded tarball rather than copied on trust. It is inlined in the manifest instead of bumping the submodule, because upstream has since deleted both glu-9.0.0.json and the whole udev directory this manifest also references. (by Lauri Ojansivu)
Fix: The .deb for resolute armhf ended with "exit code 1" and not one line saying why. It was du, whose EOVERFLOW in a 32-bit userland had been silenced with 2>/dev/null - which hid the message but not the exit status, so under set -euo pipefail the failing command substitution ended the script. Installed-Size is informational, so a package that cannot be measured is still worth shipping; that now actually holds. An ERR trap naming the line and the command is added, so the next silent failure is not silent. (by Lauri Ojansivu)
Fix: That "only" filter was written as a job-level if:, which GitHub refuses to load - matrix is not available to a job's own condition, only to its runs-on, env, name, steps and a few others. A workflow that will not load takes every workflow that calls it with it, so release-all-missing.yml failed at startup and built nothing. The decision is made in the job's env, which can see matrix, and every step asks for it. (by Lauri Ojansivu)
Misc: Every package type is built for each CPU separately, and additionally as one multi-CPU package wherever the format allows it. macOS ships a disk image per CPU AND the universal one - the universal is the download for somebody who does not know which Mac they have, the per-CPU ones are half the size for somebody who does. Windows gains a combined 32/64-bit installer, built when both halves exist, which is skipped with a note until MSYS2 has a 32-bit SFML 3 again. Flatpak already had both: a bundle per architecture and a repository serving all of them. AppImage is per-CPU only and now says why - an AppImage starts with a runtime binary for one architecture, so the format cannot express several. (by Lauri Ojansivu)
Misc: The .deb is split into tsc and tsc-data, which is what the project itself did at 2.1.0. tsc/data is 289 MB of levels, worlds, music and graphics and is byte-identical on every CPU; tsc/src is 3.7 MB. One all-in-one package per architecture meant shipping that 289 MB twelve times over, and an apt repository carrying it twelve times. tsc-data is Architecture: all, built once, and every tsc package depends on it at the same version. (by Lauri Ojansivu)
Misc: Added GitHub workflow release-all.yml, which asks which release to build for and runs all five package workflows plus Repos against that one release, so a release is the product of one run rather than of six started on different days. The release is created if it does not exist, and the CHANGELOG entry for its version becomes its release notes - so a release is described by the file the project already keeps rather than by something typed into a form and lost. Every workflow also takes the release as an input and creates it the same way on its own, which removes a chicken-and-egg problem: the .deb, Windows, Mac and Flatpak workflows used to attach to "the newest release" and fail outright when a version had none yet. (by Lauri Ojansivu)
Misc: Added GitHub workflow Repos.yml, which builds the apt, AppImage and Flatpak repositories the website serves out of the files already attached to a release. The other workflows produce packages; this produces the repositories that hand them out, so apt upgrade, zsync and flatpak update bring the next release down by themselves instead of it being another visit to the download page. Nothing is rebuilt - every file comes off the release, so a repository hands out the same bytes the release page does. They are unsigned, and the README written beside them sets out how to sign them once a GPG key exists. (by Lauri Ojansivu)
Misc: The release version is read from this file. The topmost entry that carries a number is the version the workflows tag and name their files after, so a release cannot be built for a version the changelog does not describe. (by Lauri Ojansivu)
Misc: Added GitHub workflow release-all-missing.yml, which builds only the packages a release does not already carry. release-all.yml runs five build workflows over 27 assets and the emulated ones take hours; when a run ends with some missing, as every run so far has, the only way to fill the gap was to build all 27 again. What a complete release looks like lives in one place, .github/scripts/expected-assets.sh, and each build workflow gained an "only" input so the same workflows build the subset. An asset counts as present only when its checksums are there too. (by Lauri Ojansivu)
Dependencies: Patch CEGUI so it compiles with CMake 4.2.3 (#732 by Jhonny Oliveira).
Dependencies: Drop dependency on libpcre3. This currently allows to enter invalid values into editor's edit boxes, but as long as TSC is stuck with the version of CEGUI in the repository this cannot be changed. (#730 by Marvin Gülker)
Dependencies: Update SFML to version 3 (#729 by Andrea Brancaleoni)
Dependencies: Removed dependency on tinyclipboard, use sf::Clipboard instead (#690 by Marvin Gülker, PR #695 by Bálint Kiss).
Dependencies: Upgraded mruby to 2.1.2. (#697 by Ferdinand Thiessen)
Misc: Updated extra/ files to current standards (#696 by Ferdinand Thiessen)
Misc: Added experimental MacOS support (#691 by iMacker2020).