Search the Community

For an as-yet unknown reason, this commit seems to break XML parsing on Linux: #6439: Use xmlReadFile instead of xmlParseFile which has been deprecated and removed. Privatise Document() constructor accepting an xmlDocPtr. As far as I can see, the commit is entirely correct. xmlParseFile is indeed deprecated, and the new usage of xmlReadFile matches what the libxml2 examples are suggesting. But the result is that although the xmlDoc* returned from the function is not NULL, nothing XML-related works, the entire registry system returns only empty values, and almost all of the tests are broken (because the main radiant core cannot be initialised without any registry values available). Changing back to xmlParseFile makes the problem go away but is an unsatisfactory solution because it specifically reintroduces a deprecated function call. I am not sure whether this is a bug in the specific version of libxml2 on my Ubuntu system, or something incorrect about how we are calling xmlReadFile (i.e. perhaps it requires an encoding or a particular non-default option to correctly process our XML files). Unfortunately like many of the core GNOME C libraries, the documentation is bare-bones and explains almost nothing (like what any of the parsing options actually mean), and I cannot see an obvious way to ask libxml2 to return meaningful errors, or to query exactly what might be wrong with a constructed xmlDoc* object. It makes me wonder if it would be better in the long term to ditch the reliance on libxml2 and instead use one of the light-weight C++ XML parsing libraries like RapidXml or pugixml instead. Not exactly a trivial change but might not be too cumbersome since the existing XML code is wrapped in our own xmlutil classes and not generally used directly by the rest of the codebase.

I've got a Windows 11 machine. TDM players on Linux are running into problems with my mission; it appears these are Linux-specific issues. I'd like to have a Linux install of TDM, to verify these issues (and maybe be able to submit bug reports). What's the best technique for getting a Linux install on my Windows computer? My ignorance of Linux knows no bounds . How do these options look? https://www.windowscentral.com/software-apps/windows-11/how-to-run-any-linux-distro-alongside-windows-11 Thanks!

I am curious as to which distributions and tool version are known to work when compiling either the 2.10 source archive or svn trunk. Cmake errors out with both Archlinux and Mint 21 for me. For good measure I will include some information I gathered about these errors, but I just want to be able to successfully build tdm on something. (My end goal is to compile in either pulseaudio or pipewire support for openal if that's possible; even though this thread got my audio working (arch audio subsystem is pipewire{,-alsa,-audio,-pulse} & jack2 ) ) I've also tried compiling against the latest svn trunk, that fails too, although the point in which it fails is slightly different. What do the developers use to build the linux release? System information for the failed builds against the 2.10 archive: System #1: cmake 3.22.1 | gcc 11.3.0 | kernel 5.15.0-56-generic | distro Linux Mint 21 System #2: cmake 3.25.1 | gcc 12.2.0 | kernel 5.15.83-1-lts | distro Arch Linux src archive used: sha256sum thedarkmod.2.10.src.7z 73aa974635293e6ca07396be19901355f8224637bdf3ce73404b8eef74148a1c thedarkmod.2.10.src.7z Build command from root of extracted src: [ -d build ] && rm -rf build mkdir build && cd build && cmake --debug-output --loglevel=DEBUG -DCMAKE_BUILD_TYPE="Release" .. &> cmake.$distro.log && \ make -d --debug=a -j &> make.$distro.log ; cd .. make.mint.log.gz make.arch.log.gz cmake.mint.log.gz cmake.arch.log.gz

A couple of users have pretty consistent crashes with High Expectations. I have also experienced crashes with Windows on my own machine, but very rarely. I have a debug build of 2.11, but I haven't been able to get it to crash under that yet. I've attached the logs that @irisx has provided, and @DavyJones has the exact same issue. The only thing that stood out to me was in the qconsole.log: The ambient 'snd_tunnels' (underground_forelone_loop_z) for location 'location_tunnels' is now playing. Getting threadname failed, reason: No such file or directory (2) --------- Game Map Shutdown ---------- @irisx did you say you also have some trace file? Do any other Linux users have this problem (or not)? The issue seems to occur about 1.5 seconds after the FM starts, or as soon as you start to provide input (move the mouse or start walking, etc). qconsole.log Darkmod.log

Please help to build the game from source in linux distribution (Nixos).

I'm running a fresh install of Fedora 37, and installed DarkRadiant 3.8.0 via the Flatpak installer. Trying to create a new XY view crashes DarkRadiant every time. I checked in Windows 10 and the same behavior doesn't occur. Are there any log files or other info I can present that might help?

Question: I was wondering if installation with Flatpak is something that is considered for the future. Motivation: I recently installed Linux Mint on my laptop and found installing DR 3.0 relatively easy (ppa), so I was thinking about figuring out how to create a package for Manjaro (which I use on my main pc), but then I thought about Flatpak. Isn't that the way forward for if you want to support multiple distro's but don't have a large group of interested Linux maintainers? Currently it is: Debian: There is a maintained package, Ubuntu: There's a ppa All other distro's: built from source While with Flatpak it seems you just need one way of installation for all distro's. I could be wrong though.

The title says it all.... I just got myself a dual monitor setup, with a cheap display on the left side (DVI) and a better display on the right side (VGA/HDMI). The right side display is my main display, and the one I would like to run Darkmod on. The game is set to run full screen, and it ALWAYS opens on the left monitor. Is there something in the game that makes it run on the wrong monitor? I googled the problem and found no workable solutions, but other people did complain that only some games did this, so I'm guessing it's possible, but I don't really have any idea how to fix this. Running Kubuntu 14.04 LTS, with Nvidia's drivers.

The way that input and windows are managed for Linux has become rather dated, causing a multitude of issues. To fix that, I am currently evaluating if we can just use a library (GLFW) to handle all of that for us. First impressions are rather positive, on my end I see generally improved behavior. However, since Linux is a rather diverse ecosystem, I need additional testers to rule out I broke something important. So if you have some time to spare, I'd appreciate it if you could give this build a try: https://ci.appveyor.com/api/buildjobs/6kbqskyx3tmla74s/artifacts/build%2Fthedarkmod.tar.bz2 Just extract to your installation, delete your darkmod.cfg and give it a spin. I'm particularly interested in input and alt-tabbing behavior. Whether it improved something for you or broke something. Thanks!

I have recently installed this on Linux Mint 20.3 and I am getting performance issues, namely the frame rate is choppy. It's still playable, but it is uncomfortable to play for too long because of the choppy visuals. I have tried lowering the graphical settings but no matter how high or low I set them I get the same result. I also have the official nvidia driver installed. On the same machine I have a Windows 7 install and it runs perfectly smooth there, so I know it's not an issue of inadequate hardware. I know I could just boot into Windows and play it but I would have preferred if I could play it on Linux since that is my main OS on this PC. Any ideas?

I'm trying to build the project using the steps on our Wiki. It just uses up all memory and then kills the terminal window I'm running it from Any ideas? https://ibb.co/RTFnLXG [url=https://ibb.co/RTFnLXG][img]https://i.ibb.co/RTFnLXG/image.png[/img][/url] Surely 16GB should be sufficient for make -j?

https://stadt-bremerhaven.de/nvidia-veroeffentlicht-quelloffene-linux-kernel-treiber-fuer-seine-gpus/

Can anyone help with the following? When running make, I get this when it gets to OpenGLRenderSystem: Never mind. I built it again without errors.

Greetings. First I would like to say a huge thanks for the continued support of this game and for TDM 2.10, it loads much MUCh faster now. However on Debian Linux I have an issue where the mouse occasionally just warps. It happens both in the game and in the menus, though obviously when it happens in the game it is quite disorienting. Anyone else experience this? I never saw it in 2.09... EDIT: Seems to have gone away when I switched window managers.

I ran into an error when compiling The Dark Mod on Linux with glibc 2.34. Building CXX object CMakeFiles/TheDarkMod.dir/tests/TestRun.cpp.o In file included from /home/dm/darkmod_src/tests/testing.h:22, from /home/dm/darkmod_src/tests/TestRun.cpp:18: /home/dm/darkmod_src/ThirdParty/artefacts/doctest/include/doctest/doctest.h:3998:47: error: size of array ‘altStackMem’ is not an integral constant-expression 3998 | static char altStackMem[4 * SIGSTKSZ]; | ^ make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:3071: CMakeFiles/TheDarkMod.dir/tests/TestRun.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/TheDarkMod.dir/all] Error 2 make: *** [Makefile:103: all] Error 2 Updating "ThirdParty/artefacts/doctest/include/doctest/doctest.h" to 2.4.8 fixed it for me. https://github.com/doctest/doctest/blob/v2.4.8/doctest/doctest.h See "Can't compile with glibc master (future 2.34): SIGSTKSZ is no longer a constant" (https://github.com/doctest/doctest/issues/473)

It occurred to me that I should submit this patch now, especially since I see evidence of others (like 'Crinkelite') compiling TDM under Linux. Based on replies to my post in my other recent thread, I realize that it has no chance for 2.05 inclusion, but I want others to have access to it now, so I'm asking that it be added to latest SVN, please. Problem/Fix Description: There is some sort of anomaly with the SCons build system (which is used only for Linux builds, not Windows builds) whereby all items get needlessly rebuilt, every time, when doing TDM builds. In fact, this was encountered by 'NagaHuntress' back in this Aug 2015 post. But, for this and various other reasons while investigating a 64-bit Linux build, she chose to completely switch from SCons to CMake, conveniently side-stepping the problem. The issue fixed by my patch has to do with the SCons (MD5) 'signature' file, which is used to decide when input files used in the build have changed. It's not 100% clear what the cause is, but it may be due to the use of the 'VariantDir()' directives in the 'SConstruct' file. Regardless of the reason, credit for the solution comes from Victor Gaydov's webpage: Both Doom3 and, therefore, TDM use a method of specifying the SCons signature file which causes this serious problem. The solution is quite simple, just as Victor stated: specify the signature file using a full path. The attached patch provides this improvement. It was tested under 32-bit Slackware 13.1 running SCons version 2.5.1 and under 32-bit Slackware 14.2 running SCons version 2.4.1, both against latest SVN (6720) and against the TDM 2.04 release. The fix means that now when you're building TDM under Linux, SCons won't (annoyingly!) rebuild the whole tree every time. This change also nicely allows the removal of a hack in the Linux build script file which was used to force the existence of a SCons signature file. Prior to this patch, if SCons was run without a signature file of the expected name already existing, it would report a long error message that began with this: OSError: [Errno 2] No such file or directory: 'scons.signatures.dblite':And, worse, it would fail to create the proper signature file ('scons.signatures.dblite'), instead creating an unwanted 'scons.signatures.tmp' file, and thereby causing ongoing grief with every successive run of SCons. This simple patch fixes both problems while also removing the inelegant work-around in the Linux build script file. Please apply to latest SVN. prevent-scons-from-rebuilding-everything-every-time.patch.txt

So if I use one of these 3 Window layouts (some of) the keyboard shortcuts don't work: Floating, Regular and Regular left I especially tested keys Ctrl-Z and Esc. With other layouts they work fine. This btw. has nothing to do with the shortcuts not showing up in the menu's, because the keyboard shortcuts themself do normally work. Also, I don't really have a big issue with it, because I use Splitpane as window layout. I just report this issue. I use Darkradiant 2.11.0 amd64 on Manjaro Linux (based on Arch linux). So I build it from source.

Hi, I'm trying to install the latest release version of TDM on Gentoo Linux (and I'm aware that there is an unofficial ebuild but I prefer to keep the number of third-party repositories to an absolute minimum). Anyway, it seems to be impossible for the installer to receive any data at all, except for the config file. If however I check the "Skip installer self-update" option in Advanced Settings it attempts to download manifest files for all the release versions but doesn't receive any of them (curl error 56 - Failure in receiving network data). If I try to download any of these files manually using a browser, the browser complains that the source files can't be read. It doesn't seem to be a problem on my end. Kind of seems like the files are simply not publicly accessible but I'm not sure. Enclosed is the complete log file for reference. tdm_installer_1634569973.log

This was discussed briefly on Discord some time ago, I wanted to bring it up here as well for consistency. I don't believe it's an emergency but do consider it an important change especially later down the road, as Linux is slowly moving away from x11 with many distros already going full Wayland by default. In my case I'm pretty much waiting for KDE Plasma to fix a few bugs left with the DE before permanently switching from X11 to wayland too, I might be able to make use of it rather soon if they do. With the new input and rendering system introduced after 2.09 and available for testing in the dev builds (GLFW) we're on our way to having a Wayland compatible build of our engine. Meaning the engine is able to render natively to the WL pipeline, without having to go through the fake x11 server simulated by the Wayland session for compatibility with X exclusive apps. This not only offers proper compatibility for Wayland users, but may improve performance on various fronts which was one of the goals of the new rendering framework. From what I remember @cabalistic telling me, we can't have the same engine for both x11 and Wayland: It must be compiled against different system packages to produce one version or the other. For Linux users the installer may need to offer two engine binaries in this case, or an option to pick which version you'd like to install if that's better. Other than that I understand it should be able to produce in theory, as SDL2 and GLFW both offer Wayland compatible libraries to compile the engine against. I'm not familiar with the C++ code in the slightest so I'll let the experienced developers complete this with the proper technical additions.

When having a dark theme applied in Linux, text in the Properties and console window is hard to see because it is black text on a dark window background (the same text color when light theme applied). Is there a way to change this text color manually?