Search the Community

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

I'm writing a recipe to package the game for Linux, and it to work system wide. The recipe compiles everything from source-code, as usually required by Linux distributions for security. If I compile as it is, everything is fine. But if I also try to compile the third party libraries by myself, even when they compile successfully, the process fails when linking to openal: There's also a second problem. "ThirdParty/cmake_find_package/tdm_find_package.cmake" expects gcc to be version 5, but my Linux distribution only offers gcc 10: If I compile libraries by myself, that gcc dir is "gcc10". Although this is easy fixed by substituding the string with:

I'm trying to follow the DR compilation instructions, using a Linux Mint system (apparently Mint is different enough from its near relatives to be unable to resolve dependencies for the Debian and Ubuntu .deb files). I installed packages based on the list given for Ubuntu 19.xx / 18.xx / 17.xx, except that apparently libwxgtk3.0-dev is now called libwxgtk3.0-gtk3-dev. I get the following errors during `make`: Making all in script make[3]: Entering directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' CXXLD script.la /bin/bash: --exec-prefix: command not found /bin/bash: --includes: command not found /bin/bash: --libs: command not found /bin/bash: --cflags: command not found /bin/bash: --ldflags: command not found /bin/bash: --extension-suffix: command not found /bin/bash: --help: command not found /bin/bash: --configdir: command not found make[3]: *** [Makefile:617: script.la] Error 127 make[3]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' make[2]: *** [Makefile:446: all-recursive] Error 1 make[2]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins' make[1]: *** [Makefile:755: all-recursive] Error 1 make[1]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant' make: *** [Makefile:496: all] Error 2 A bit of Googling suggests those -- strings are options for python-config, so why they're being treated as shell commands has me mystified.

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.

Hi, I need to know what the code is to use Spoiler Tags. I am using my tablet and I don't have the options to use anything, like spoiler tags, quote tags, text changes etc. Thanks

I'm getting a compilation error on Archlinux x86_64 game/Shop/../Missions/../pugixml/pugixml.hpp:1071:2: error: reference to 'basic_string' is ambiguous Linux 4.7.2-1-ARCH #1 SMP PREEMPT Sat Aug 20 23:02:56 CEST 2016 GNU/Linux Log https://ptpb.pw/SYP2

Attached is a simple patch to 'include/irenderable.h' that allows DarkRadiant (both 2.1.0 and the latest code from SourceForge github) to compile under Linux (specifically, 32-bit Slackware 14.2). With this patch, I was able to compile and run DarkRadiant, but it immediately crashes. More on that in a separate thread. DarkRadiant-compile-under-Linux.patch.txt

Hello all, this is not exactly a generic offer for help... While compiling The Dark Mod with GCC on Linux I have witnessed an endless stream of warnings. I would like to resolve those warnings so that the code becomes standard C++. And I would like to know if the project is interested in the resulting patches. I have started already. Just because, believe it or not, for me that's somehow fun. I have enabled all warnings and pedantry, identified about 30 types of warning, and I am bashing them one by one. An example of motivation: GCC (6.2) tells me: renderer/Model_ase.cpp: In function ‘void ASE_KeyGEOMOBJECT(const char*)’: renderer/Model_ase.cpp:724:37: error: argument to ‘sizeof’ in ‘void* memset(void*, int, size_t)’ call is the same expression as the destination; did you mean to dereference it? [-Werror=sizeof-pointer-memaccess] memset( ase.currentMesh, 0, sizeof( ase.currentMesh ) ); ^ That is: it finds a bug (or at least it looks so to me), and it even tells the right solution. And this warning hasn't been noticed because swamped in others that are surely harmless. Of course this example shows also the limit of the approach: what if that unusual statement was intentional? I would be introducing a bug instead. So I may need to ask some questions along the way. I intend to direct my effort to ISO C++ 2003 compliance first, and then consider ISO C++ 2011, if the project thinks it's ok. But that will be far from now. I also do not intend to touch the C code, because I am not as fluent there. This also means that the result should be welcome by any compliant compiler on any platform, and by now I suppose even MicroSoft compilers are compliant to C++03. I can imagine the project would rather see this energy devoted to other items in the to-do list... but in my mind this one is a necessary step toward bug fixing. Ball in your field, comments are welcome.

I recently halfheartedly tried to comile TDM on my Debian Stretch (amd64) system. I didn't succeed, mostly due to the fact that I couldn't find any recent compiling instructions. The file COMPILING.txt just directs to this wiki site which seems terribly outdated and many of the listed dependencies aren't available in recent Debian versions anymore. I tried to just compile it by running scons, but I ran into lots of compilation errors, probably because I missed to do many things, which recent compiling instructions would tell me to do. Did I just not find recent instructions or are there really no recent instructions?

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

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?

I have Debian 8.2 Jessie (stable) on my machine. There ar no repos for darkradinat, so i tried compile it by my self. Unfortunately compilation fails with errors: Making all in install/i18n make[2]: Entering directory '/home/ritvars/GameDevelopment/DarkRadiant-master/install/i18n' test ! -f ./darkradiant.pot || \ test -z "de.gmo" || make de.gmo make[3]: Entering directory '/home/ritvars/GameDevelopment/DarkRadiant-master/install/i18n' for dir in *; do \ if test -d ${dir}; then \ cp ${dir}/LC_MESSAGES/darkradiant.po ${dir}.po; \ fi; \ done : --update --lang=de de.po darkradiant.pot rm -f de.gmo && : -c --statistics --verbose -o de.gmo de.po mv: cannot stat ‘t-de.gmo’: No such file or directory Makefile:333: recipe for target 'de.gmo' failed make[3]: *** [de.gmo] Error 1 make[3]: Leaving directory '/home/ritvars/GameDevelopment/DarkRadiant-master/install/i18n' Makefile:370: recipe for target 'stamp-po' failed make[2]: *** [stamp-po] Error 2 make[2]: Leaving directory '/home/ritvars/GameDevelopment/DarkRadiant-master/install/i18n' Makefile:742: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/ritvars/GameDevelopment/DarkRadiant-master' Makefile:482: recipe for target 'all' failed make: *** [all] Error 2 can someone help to fix this? Thanks.