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

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.

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?

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?

Jumping back in after several years away. Very excited to see the new maps! I found however that on startup, the game window is very small and I can't seem to expand it. Using Ubuntu 18.04. Not sure what version of TDM I have, but I downloaded it yesterday so it's whatever is current now.

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?

Maybe the game should be available on that stores because all the new users can download a get ready to play the game, also i think that this game will be at the top of the list of the games because its quality.

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)

Well the problem is that you cannot for some reason edit the gamma&brightness inside TDM and in the .ini file, tried it and no result, here is the terminal output(I restarted the game to show that it does not even register me moving the sliders nor applying any change just in case):

The compilation for the latest version pulled from Github fails for me with the following error messages: /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::~DeflatedInputStream()': DeflatedInputStream.cpp:(.text+0x1b): undefined reference to `inflateEnd' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::read(unsigned char*, unsigned long)':/usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::~DeflatedInputStream()': DeflatedInputStream.cpp:(.text+0x1b): undefined reference to `inflateEnd' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::read(unsigned char*, unsigned long)': DeflatedInputStream.cpp:(.text+0xaa): undefined reference to `inflate' /usr/bin/ld: DeflatedInputStream.cpp:(.text+0xca): undefined reference to `inflate' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::DeflatedInputStream(InputStream&)': DeflatedInputStream.cpp:(.text+0x149): undefined reference to `inflateInit2_' collect2: error: ld returned 1 exit status make[2]: *** [radiantcore/CMakeFiles/radiantcore.dir/build.make:4154: radiantcore/libradiantcore.so] Error 1 make[1]: *** [CMakeFiles/Makefile2:787: radiantcore/CMakeFiles/radiantcore.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 DeflatedInputStream.cpp:(.text+0xaa): undefined reference to `inflate' /usr/bin/ld: DeflatedInputStream.cpp:(.text+0xca): undefined reference to `inflate' /usr/bin/ld: CMakeFiles/radiantcore.dir/vfs/DeflatedInputStream.cpp.o: in function `archive::DeflatedInputStream::DeflatedInputStream(InputStream&)': DeflatedInputStream.cpp:(.text+0x149): undefined reference to `inflateInit2_' collect2: error: ld returned 1 exit status make[2]: *** [radiantcore/CMakeFiles/radiantcore.dir/build.make:4154: radiantcore/libradiantcore.so] Error 1 make[1]: *** [CMakeFiles/Makefile2:787: radiantcore/CMakeFiles/radiantcore.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 Any idea how I can fix this? Thanks

This issue has been occurring in the last few weeks, and my first thought was that it is due to a regression that happened during the code reorganisation and the necessary changes to GL context handling. In my Ubuntu 20.10 machine I walked back the git history up to the point of the DR 2.8.0 release, but as it turns out, the problem is happening there too. When switching between Media and Texture tabs, the GL widget is not refreshed, unless you resize the tabs using the splitter between cam and orthoview: So I launched my other VM running Ubuntu 19.10 and was rather surprised that this problem does not happen there, even with the latest git checkout: I'm not sure where this behaviour is coming from all of a sudden. While I can't rule out that DR is doing something wrong in terms of context handling, there sure seems to be a difference between the two Ubuntu 19/20 setups. Any suggestions on how to go ahead and find out where the problem is rooted? The one idea I have: Since Ubuntu 19 is using wxGTK 3.0.4 and Ubuntu 20 is using the latest wxGTK 3.0.5, I will try to compile the older wxWidgets 3.0.4 release from source and use that in the newer Ubuntu 20 version, to see if the problem goes away.