Search the Community

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

I have created an software that can install The Dark Mod in any Linux system wide. https://gitlab.com/es20490446e/darkmod-linux

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

for the most part it is indeed only the commands that differ some are even the same as on DOS with maybe a few differences like echo then there are some that we also had in dos like rm=remove cp=copy the unix variants have more options but besides that the functionality is mostly the same dir in unix is called ls though. where linux can still be a bit hard for the uninvited is when it comes to drivers, linux has nothing with the functionality of the device manager from windows and making one is allmost impossible due to how things work in a unix environment. you can get something that shows you installed devices but it does not allow you to change driver parameters or for that matter the driver, you still need to do that with commands. sure back in the DOS days we mostly had to do the same (setting IRQ's DMA etc.) but the commands used were quite a bit simpler as well. where linux would truely shine would be in something with a predetermined hardware set (like a steam deck or steam box) for a gamer atleast, my guess is that is why they decided it would be a good project. also unix is quite a bit more secure by default than windows, thats not to say you cant get an infection but it is usually not fatal. also the sheer amount of programs you can get many of which have the same functionality but rely on certain OS gui features (OpenBOX MIR or other variants of the X WIndow system) which not allways play well with the choosen variant you decide to use. In essence it has become a mess and while it is great for those who like as many choices as possible it does have its pitfalls.

I use only singleplayer games (TDM is a nice one,you know? ), I don't like the gamer gildes of the MMORPG, Iwant to go to my like in a game. Yes, tho good old MSDOS times, creating pseudo UI with ANSI codes and writing Batch files (apart, old MSDOS is released as OpenSource, if someone want). First Windows was an experience, between crashes, BSOD and desperate wanting to throw the thing out the window for the eternal updates. But it was no longer necessary to use the commandline, although you can continue using it even in current Windows. In Linux it is still more necessary, but also less and less. The logic is the same in the commands, they only differ between DOS and Linux with different names for the commands and for this reason Linux for old Windows users from the dawn of time is not a big problem either. https://www.windows93.net

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.

I use Linux already, but sometimes people want me to look at their Windows computers. Funny story, an old lady that I used to know would come to me when she had computer problems. So, one time she wanted me to fix up her Windows laptop, and I gave her a laptop running Linux. I actually wanted her to get a Chromebook, but she was broke, as by that point I was already fed up with Windows and not interested in dealing with it anymore. Anyway, she used the thing for a year or two, was happy with it, then she passed away. Her daughter took over her things, and at that point, the daughter had a choice of laptops; the old crappy one with Windows, and the slightly less old and slightly less crappy one with Linux. And guess which one she took. ha-ha-ha I think the best way to get revenge against Microsoft isn't to pirate their software, but to instead help transition friends and family to something else. The geeks can make them irrelevant in consumer space, and these sleazy tactics do not fly in the corporate world. Pretty much all of the people I know who can afford to, have already left Windows for Macs.

I know, it's just the only easy way I can think of. Fixed script names is what we have now, tdm_custom_scripts.script or tdm_user_addons.script: Every mod will use them up and thus take them away from other mods. We need something that's dynamic and unlimited. A better alternative is a prefix to indicate you want auto-running of that script: Anything called "scripts/include_*.script" would be a good one, just use an unique name and call yours "include_mod_something.script" which will work if no one else names theirs "mod_something". Even better: Have a keyword at the beginning of the script! Like how scripts in Linux start with #!/bin/bash so file managers know how to preview them: Similarly we could add something like #autoexec at the beginning of ours, though this approach requires the engine looping through all script files to detect this keyword. We could imagine making tdm_user_addons.script unique per pk4. But I haven't even mentioned this one as it goes against how the file system works: You can't have multiple files with the same name and different contents, the latest archive in alphabetical order must always override a file loaded by an earlier archive. What gets close to that is a special text file in each pk4 like a package.txt which references the inclusion script as a flag. FM's kind of do that with darkmod.txt: When each pk4 is iterated by the engine at startup, it could read a script name mentioned there and execute the file referenced. But this seems more complicated than necessary unless this configuration is used for more stuff, maybe to list loaded mods in the main menu with their title / description / author / version the same way missions are?

Why? It looks quite bad. Btw. There is still the crash to desktop under Linux when using the special saveroom option. It does create the save, so after restart I can load from it.

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

Black Parade is released ! https://www.ttlg.com/forums/showthread.php?t=152429

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.

In the beta-testing forum, 'Baal' reported TDM 2.05-beta crashing under Linux. This is my report on the investigation of that problem, with suggested fixes and work-arounds. TLDR: Believe it or not, this all comes down to a bunch of bad timestamps in some zip files! Three of the four 'tdm_update_2.0{0-3}_to_2.0{1-4}.zip' files used to update TDM from a "base" 2.00 installation to version 2.04 have illegal timestamps on several of the files within the zip file! These need to be fixed and the mirrors need to update before this problem will start to go away. Also, this problem may linger, semi-dormant, for any Linux users who have already updated their TDM installation using any of the 3 bad files (or for any Linux 2.05-beta testers since that update file is affected too). But the back-story is far more involved, so for those interested, please read on.... Details: This gets a bit hairy, so bear with me, folks! Baal had helpfully reported both the output of the debugger after a crash and several missions for which the crash occurred. Using that information, I was able to easily duplicate the crashing. (The simpler missions that I had been testing with prior to that time did not exhibit the sort of crashes that Baal was seeing.) Running the same missions as Baal, I was greeted with the exact same sort of crashing (under 32-bit Slackware 14.2 Linux in my case). With taaaki having granted me access to the 2.05-beta source code, I was able to track this down more precisely by building a proper 'debug' build. Even though it was obvious where the crash was occurring now, the cause was not immediately evident. (This was made more difficult by my total inexperience with the TDM code, especially in the area of the crash -- resource file processing). Of course, a simple hack to prevent the crash was possible, but that would simply be "treating the symptoms" rather than "curing the disease" and I really hate it when people do that (myself included!). And even such a quick hack would have meant that the resource in question failed to load ("WARNING:Couldn't load image: models/darkmod/props/textures/gaslight1_d"), which would then have unknown (to me, as a non-modeler) ramifications later on during game-play. I suppose a missing resource would simply not be rendered, but for all I know, that might have just caused a crash later on in some other part of the code! So the "root" cause had to be determined, which meant digging deeper. All of the crashing missions seemed to crash right after loading the "gaslight1" resource, so I spent some time trying to understand what might be wrong with that particular resource and the files it's comprised of. That turned out to be a "red herring", unfortunately. There's nothing special about that resource -- it just happened to be the 1st one affected by this issue that was loaded in the missions that Baal happened to be testing. Eventually, by digging around more in the code (oh, how I hate C++) and testing, I became suspicious of the timestamps on the resource files. It's not intuitive at all (to me), but the processing of some of these TDM "resources" is based on timestamps. More specifically, getting that bogus timestamp from a file within a PK4 file results in the low-level 'ReadFile()' routine returning a timestamp of -1, which screws things up further down the line in very subtle ways that ultimately manifests itself as an unprotected attempt to write to a null pointer, thereby crashing the game! Once I understood that, I soon realized that there were several "child" resource files (i.e. files within the PK4 "parent" file) with "weird" timestamps, including one of the aforementioned "gaslight1" files. A digression to explain something important for those unaware.... Unix (and Linux) OSes commonly store time values as "seconds since UTC midnight on 01 Jan 1970". Under a 32-bit Linux OS (regardless of whether it runs on a 64-bit CPU or a 32-bit CPU), the timestamps are stored as a 32-bit signed integer. This leaves a maximum date/time of '2^31 - 1' (i.e. 2,147,483,647) seconds since 01 Jan 1970. That means that it's only practical until the date/time shown: ==> TZ='-0000' date --date '@2147483647' Tue Jan 19 03:14:07 2038 This is the well-known "Y2038" problem. On a 64-bit Linux OS, the timestamps are, unsurprisingly, stored as a 64-bit signed integer. This leaves a maximum date well past all of our lifetimes, even for those who plan to have a Futurama-style head-in-a-jar someday. So until TDM becomes a native 64-bit app on Linux, that particular part of this problem could continue, due to inattention to timestamping of files. --------------------------------- Now back to the main story... When I looked at several of the resource files contained within the various PK4 files, I saw many with the timestamp "12-31-2077 18:59". That's completely illegal and unrepresentable on a 32-bit Linux system! But I found that when I extracted the resource files from those PK4 files, those odd timestamps were conveniently(?) converted to the maximum timestamp value, yielding the aforementioned date/time of 19 Jan 2038 03:14:07. And TDM runs fine like that! Furthermore, if you replace the original PK4 file with one that you create yourself (after Linux has "fixed" the timestamps by way of file extraction) by re-zipping the extracted resource files, then TDM will run fine with that new PK4 file too. OK, those are nice work-arounds, but it's still just "treating the symptoms". Aside: My cursory testing with Windows (XP Home SP3) shows that it seems to treat timestamps differently. The PK4 files with the bogus timestamps show up in Windows (using WinZip) as "12/31/2077 6:59 PM", so that is presumably a legal timestamp to Windows. (A quick Internet search turned up nothing obvious.) Unfortunately, I next turned my attention toward the 'tdm_update' app, thinking that it was the most likely culprit, since I'd seen some console output about it "Performing cleanup steps and correcting bad dates in PK4 files". I spent a long time looking through that mostly uncommented, C++ code (did I mention how much I hate C++ code?), hacking away to add console and log output, and hacking it to only run the "correct bad dates in PK4 files" step. That turned out to be mostly a waste of time. I could not get it to corrupt any of the files it handled such that they had an egregiously wrong timestamp (but more on that later). I next started downloading, from each of the common TDM mirrors, various PK4 files which, on my system, contained files with bogus timestamps. But I saw no evidence of bogus timestamps in any of the downloaded files, suggesting that something else was afoot here. So I went back and did a test install of 2.00 followed by a 2.00 -> 2.04 upgrade. When it finished, there were many files within various PK4 files that had the bogus ("31-Dec-2077 18:59:58") timestamps! Now, finally, I could smell blood! At this point, I was still suspicious of the 'tdm_update' process and its functionality designed to alter the timestamps of the files in the PK4 file. But some more checking and pondering led me to the zip files that the 'tdm_update' process uses. Eureka!!! That's it! Those 'tdm_update_2.0{0-3}_to_2.0{1-4}.zip' files are full of bad timestamps! Now I was finally at the real source of these problems! Those bad timestamps are filtering down into the resource files causing mayhem for Linux users who just happen to load the wrong mission! The bad timestamps in the 'tdm_update_2.0{0-3}_to_2.0{1-4}.zip' files are especially egregious! They're essentially all "15-31-2107 31:63" (the 15th month, 31st day of year 2107 at 31:63)! What the heck? Various expletives deleted here... A little research (actually done well prior to this point, while I was still head-scratching) told me that Zip files use the old IBM/MS-DOS format for date+time representation (for those of us old enough to have worked with it but just young enough to still remember having done so!). In essence, those bogus timestamps have every bit set! So, basically: Year (7 bits): 127 (2107-1980)Month (4 bits): 15Day (5 bits): 31Hour (5 bits): 31Minute (6 bits): 63Seconds (5 bits): {seconds}/2Why those timestamps are getting set that way is still a mystery to me. Suggested Fix: Whoever built those 5 'tdm_update_2.0{0-4}_to_2.0{1-5}.zip' files needs to take a look at their system and/or the source (another SVN tree?) for those files used in the zip files! Find the reason for the bogus, illegal timestamps on the input (resource) files and re-generate all 5 zip files. Actually, the 1st one ('tdm_update_2.00_to_2.01.zip') has no bad timestamps and could be skipped. Make sure the updated files get picked up by all known TDM mirror sites. Then we need to strongly suggest to all Linux users of TDM that they revert to the TDM 2.00 distribution and upgrade again, using only newly downloaded 'tdm_update_2.0{0-3}_to_2.0{1-4}.zip' files, to TDM 2.04. Aftermath: Now, having identified the real problem, what are the ramifications? Fortunately, this doesn't seem to affect Windows users, presumably due to Windows' use of a different timestamp method than Unix/Linux. I didn't know initially how or if this affects users on a 64-bit Linux OS but with 32-bit ("multi-lib") capability installed. All my testing was done on native 32-bit Slackware 14.2. But I went ahead and installed 64-bit Slackware 14.2 with 32-bit "multilib" capability added on, using a spare partition of my "TDM testing" HDD. My suspicion was confirmed -- that environment is equally (i.e. badly) affected by these bogus timestamps, so I suspect that these problems would, left unchecked, affect all Linux users who load the "wrong" missions with 2.05. I downloaded the same file ('tdm_update_2.03_to_2.04.zip') from 3 mirrors ('mirror.helium.in-berlin.de', 'www.fidcal.com', and 'darkmod.taaaki.za.net') and they all have the same bogus, illegal timestamps, so this is not just a bad mirror somewhere. A potentially bigger issue is that all those "broken" PK4 files are presumably out there "in the wild". And, even in 2.04, this problem exists! Therefore, I suspect some of these resource files with a bad timestamp are little "time-bombs" just waiting for a Linux user to run a mission that (either now or in the future) uses that object, especially if it applies either the 'makeAlpha' or 'makeIntensity' operation. In other words, this problem could, in theory, be the source of any number of TDM crashes at mission loadup on Linux systems. Eventually, this problem will work itself out, but it could linger for a long time unless Linux users do a wholesale re-install from 2.00 up, and only after all the update zip files have been repaired. Fortunately, we may have been a bit luckier with the 2.04 resources -- I loaded over a dozen missions in 2.04 and none of them crashed, indicating that none of them accessed any of the objects (at least on initial load) using the bad timestamps, at least in ways that trigger the crash (i.e. by applying either the 'makeAlpha' or 'makeIntensity' operation). But of course, there are far more untested missions that could cause a crash -- I simply don't know how to generate a list of resources that a given mission uses, otherwise I'd simply scan them all looking for "bad" objects. As hinted at above, this problem also exists in the zip file that updates a 2.04 installation to 2.05-beta, so that file needs to be fixed as well as the 4 previous ones. Work-Arounds: Until the relevant zip files are "repaired", Linux users with adequate disk space could simply extract the content of all the PK4 (zip-format) files into the same directory containing the PK4 files -- i.e. their run-time directory -- optionally deleting the original PK4 files. My tests show that there should be no need to eliminate, move, or re-name the PK4 files. The extracted content seems to be used in preference to equivalent content buried in a PK4 file. Optionally, those extracted files could be re-compressed into PK4 files, but there seems to be little point in doing so. Alternatively, a hack could be placed into the TDM code to allow TDM to continue running when it encounters any resources with one of these bogus timestamps, but that's not something I'd recommend (and it would be required in at least 2 spots). Other Issues and Thoughts: The 'tdm_update' app, while not the prime culprit here, is certainly still "suspect" in that it failed to correct the bad timestamps. I need to look into that more at some later date. It also seems to needlessly alter files' timestamps by 1 hour, which may be due to its failure to respect 'daylight saving time'. But I've seen differences of more than 1 hour too, always an integer number of hours (2 or 3, but never more, IIRC). In short, I'm still somewhat suspicious of that app's alteration of timestamps. And I wonder what led to the 'tdm_update' process being given the capability to re-generate PK4 files with embedded files having "bad" ('timestamp_year = 1980' or 'timestamp is in the future') timestamps. Why should that even be needed? It seems like another case of "treat the symptoms" without "curing the disease", but I'll admit that I don't know the history there and could be wrong. In looking into this, I've discovered some timestamp code with origins in the Doom3 engine that is not ready for 64-bit OSes! It probably wouldn't hurt to put some more protection ("hardening") in various spots in the code, like this spot where a null pointer is not checked for. Far better, IMHO, to abort TDM abruptly on someone's PC with an intelligent error message (hoping TDM will have been run from a shell window of sorts, so that such a message will be seen) than to crash and expect them (or someone else) to run TDM under a debugger. I've seen all kinds of weird warnings in the TDM console and in the shell's console from which I run TDM. I suspect that some of them may have been manifestations of this same problem, just for resources that didn't happen to cause a crash. There's so much "noise" in both the TDM (in-game) console and in the shell window from which it runs that it's hard to see legitimate problems! Closing Thoughts: My thanks to Baal for bringing this problem to our attention, running under the debugger to narrow it down, and reporting various missions that were affected by this issue. To those who've read this whole report, you have both my respect and gratitude! I've undoubtedly missed something in this lengthy explanation, so if anyone has questions, please let me know.

Body awareness please. https://forums.thedarkmod.com/index.php?/topic/20013-are-you-gonna-add-this/

after typing in the Darkradiant cloned repository folder: sudo make uninstall, and after a uninstall process, there is still the following folders left in the system:

I loved it. Awesome game. I faceplanted at the people who asked for quest markers in the Steam forums there... Herr, lass Hirn regnen. The game is so great, and so true to the original, because it doesn't hold your hand. When is the new breed of gamers gonna learn.

Why is it broken? Thanks, but I can already do that with Pix (Linux). I know how to do that, but I want to save screenshots directly at a specific resolution.

Horror themed fan mission - exploration of seemingly deserted keep in the middle of swamps. Spiders, undead, darkness. ----------------------------------------------------------------------------------------------------------------------------- This is the story about the fate of my family. My uncle, Ralph Mac Roberts, is the baron of a keep nestled deep within the Rahenaen marshes. It was once an important outpost tasked with guarding one of the few Builder roads that cross the marsh, but after the Inventor`s Guild built a system of nearby dams that flooded the whole land, the road closed and there was no longer anything to watch over anymore. The keep itself needed reinforcement against the raising water level and the trade routes become almost impassable, not only for the carriages but for lone couriers as well. There hadn`t been any messages coming from the keep for over a year and my father was about to assemble a caravan so he could go on an expedition to the keep himself. However, in the middle of the night before he was set to leave, a carrier pigeon landed on his windowsill. My father received the letter and read the apologies from my uncle and his family, excusing their long absence. As a way to make reparations for their extended silence, my uncle invited me to the keep to stay there for a fortnight or so. My uncle had instructed me to leave my horse three leagues away from the keep by the nearest charcoal burning hut and hike the remainder of the road on foot, as the trek through the marsh is treacherous for horses. The weather will be awful this time of year, but my father insists that I should go anyways to ensure that our relatives are okay. These plains become dreadfully deserted - to the point where you more expect to meet the dead than the living. And by the way - I think I`m lost. ----------------------------------------------------------------------------------------------------------------------------- Download link: https://1drv.ms/u/s!Aj1DVS465udZgVkXteBbr6cUxdPH Thanks: to the TDM team for great tools, and all the contributors for their assets, to betatesters: Amadeus, Bienie, Boiler's_hiss, Dragofer, Filizitas, Judith, nbohr1more, s.urfer, again to Amadeus for proofreading and text tweaks, and to all the players for their time! Few screenshots: http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/?p=434716 http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/?p=429558 http://forums.thedarkmod.com/topic/19886-fm-marsh-of-rahena-beta-testing/?p=434507 Enjoy! Walk-through !major spoilers! Finding a way across the marsh area: Getting inside: Bed objective: Light sources: Maps: Enemies: Room objective: Hut objective: Sealed objective: Gold: Key: Bodies:

Ack, sorry you ran into that. Yeah, the coding for swapping inventories is somewhat complicated, but if you've tracked the bug down to being caused by switching inventory items during the swap then it should be pretty straightforward to finally fix (just disallow item switching during the transition). If anyone wants to fix and test, like any other bugfix they have my blessing!

i use git clone https://github.com/codereader/DarkRadiant.git --recurse-submodules with https instead of git: is that different? since with git: nothing is downloaded at all first conclusion 2 instructions missing in debian10 install libeigen3-dev libgit2-dev second conclusion, some someelse is still missing git clone https://github.com/codereader/DarkRadiant.git --recurse-submodules Cloning into 'DarkRadiant'... remote: Enumerating objects: 162889, done. remote: Counting objects: 100% (33651/33651), done. remote: Compressing objects: 100% (10563/10563), done. remote: Total 162889 (delta 24575), reused 31976 (delta 22932), pack-reused 129238 Receiving objects: 100% (162889/162889), 96.95 MiB | 3.30 MiB/s, done. Resolving deltas: 100% (124371/124371), done. sudo apt-get install git cmake pkg-config gettext zlib1g-dev libjpeg-dev libwxgtk3.0-dev libgtest-dev sudo apt-get install libxml2-dev libsigc++-2.0-dev libpng-dev libftgl-dev libglew-dev libalut-dev libvorbis-dev python3-dev synaptics Installed the following packages: libeigen3-dev (3.3.7-1) libeigen3-doc (3.3.7-1) Installed the following packages: libgit2-27 (0.27.7+dfsg.1-0.2) libgit2-dev (0.27.7+dfsg.1-0.2) libhttp-parser-dev (2.8.1-1+deb10u2) libmbedcrypto3 (2.16.0-1) libmbedtls-dev (2.16.0-1) libmbedtls12 (2.16.0-1) libmbedx509-0 (2.16.0-1) libssh2-1-dev (1.8.0-2.1) cd DarkRadiant ~/DarkRadiant$ cmake . -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") -- Checking for module 'libxml-2.0' -- Found libxml-2.0, version 2.9.4 -- Checking for module 'sigc++-2.0' -- Found sigc++-2.0, version 2.10.1 -- Checking for module 'ftgl' -- Found ftgl, version 2.4.0 -- Checking for module 'freetype2' -- Found freetype2, version 22.1.16 -- Checking for module 'gl' -- Found gl, version 18.3.6 -- Checking for module 'glew' -- Found glew, version 2.1.0 -- Checking for module 'libjpeg' -- Found libjpeg, version 1.5.2 -- Checking for module 'libpng' -- Found libpng, version 1.6.36 -- Checking for module 'openal' -- Found openal, version 1.19.1 -- Checking for module 'ogg' -- Found ogg, version 1.3.2 -- Checking for module 'vorbisfile' -- Found vorbisfile, version 1.3.6 -- Checking for module 'x11' -- Found x11, version 1.6.7 -- Checking for module 'zlib' -- Found zlib, version 1.2.11 -- Checking for module 'glib-2.0' -- Found glib-2.0, version 2.63.5 -- Checking for module 'eigen3' -- Found eigen3, version 3.3.7 -- Found wxWidgets: -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0;-lwx_gtk2u_stc-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_xrc-3.0;-lwx_gtk2u_aui-3.0 (found version "3.0.4") -- Found Python: /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so (found version "3.7.3") found components: Development -- Checking for module 'libgit2' -- Found libgit2, version 0.27.7 -- Checking for module 'gtest' -- No package 'gtest' found -- Checking for module 'gtest_main' -- No package 'gtest_main' found -- Configuring done -- Generating done -- Build files have been written to: /home/chris/DarkRadiant NOTE: /usr/include/gtest /usr/include/gtest/gtest-death-test.h /usr/include/gtest/gtest-message.h /usr/include/gtest/gtest-param-test.h /usr/include/gtest/gtest-param-test.h.pump /usr/include/gtest/gtest-printers.h /usr/include/gtest/gtest-spi.h /usr/include/gtest/gtest-test-part.h /usr/include/gtest/gtest-typed-test.h /usr/include/gtest/gtest.h /usr/include/gtest/gtest_pred_impl.h /usr/include/gtest/gtest_prod.h /usr/include/gtest/internal /usr/include/gtest/internal/custom /usr/include/gtest/internal/custom/README.md /usr/include/gtest/internal/custom/gtest-port.h /usr/include/gtest/internal/custom/gtest-printers.h /usr/include/gtest/internal/custom/gtest.h /usr/include/gtest/internal/gtest-death-test-internal.h /usr/include/gtest/internal/gtest-filepath.h /usr/include/gtest/internal/gtest-internal.h /usr/include/gtest/internal/gtest-linked_ptr.h /usr/include/gtest/internal/gtest-param-util-generated.h /usr/include/gtest/internal/gtest-param-util-generated.h.pump /usr/include/gtest/internal/gtest-param-util.h /usr/include/gtest/internal/gtest-port-arch.h /usr/include/gtest/internal/gtest-port.h /usr/include/gtest/internal/gtest-string.h /usr/include/gtest/internal/gtest-tuple.h /usr/include/gtest/internal/gtest-tuple.h.pump /usr/include/gtest/internal/gtest-type-util.h /usr/include/gtest/internal/gtest-type-util.h.pump /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libgtest.a /usr/lib/x86_64-linux-gnu/libgtest_main.a /usr/share /usr/share/doc /usr/share/doc/libgtest-dev /usr/share/doc/libgtest-dev/changelog.Debian.gz /usr/share/doc/libgtest-dev/copyright /usr/src /usr/src/gtest ~/DarkRadiant$ make Scanning dependencies of target math [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/AABB.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Frustum.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Matrix4.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/Plane3.cpp.o [ 0%] Building CXX object libs/math/CMakeFiles/math.dir/SHA256.cpp.o [ 0%] Linking CXX shared library libmath.so [ 0%] Built target math Scanning dependencies of target xmlutil [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/Document.cpp.o [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/Node.cpp.o [ 0%] Building CXX object libs/xmlutil/CMakeFiles/xmlutil.dir/XmlModule.cpp.o [ 1%] Linking CXX shared library libxmlutil.so [ 1%] Built target xmlutil Scanning dependencies of target scenegraph [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/ChildPrimitives.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/InstanceWalkers.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/LayerUsageBreakdown.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/ModelFinder.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/Node.cpp.o [ 1%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeOperation.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeOperationBase.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/MergeActionNode.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/GraphComparer.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/merge/ThreeWayMergeOperation.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/SelectableNode.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/SelectionIndex.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/TraversableNodeSet.cpp.o [ 2%] Building CXX object libs/scene/CMakeFiles/scenegraph.dir/Traverse.cpp.o [ 3%] Linking CXX shared library libscenegraph.so [ 3%] Built target scenegraph Scanning dependencies of target wxutil [ 3%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/ConsoleView.cpp.o [ 3%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/DeclarationTreeView.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/KeyValueTable.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ResourceTreeView.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ResourceTreeViewToolbar.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/ThreadedResourceTreePopulator.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeModel.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeModelFilter.cpp.o [ 4%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/TreeView.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dataview/VFSTreePopulator.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/decl/DeclarationSelectorDialog.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/decl/DeclarationSelector.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/DialogBase.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/Dialog.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/dialog/MessageBox.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/fsview/FileSystemView.cpp.o [ 5%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/fsview/Populator.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/DirChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/EntityClassChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/FileChooser.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/FreezePointer.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/GLWidget.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/menu/PopupMenu.cpp.o [ 6%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/menu/FilterPopupMenu.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/ModalProgressDialog.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/MouseToolHandler.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/PanedPosition.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/PathEntry.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/GuiRenderer.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/GuiView.cpp.o [ 7%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/ModelPreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/ParticlePreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/preview/RenderPreview.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/SerialisableWidgets.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/DeclarationSourceView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/DefinitionView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/sourceview/SourceView.cpp.o [ 8%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/Splitter.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/WindowPosition.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/WindowState.cpp.o [ 9%] Building CXX object libs/wxutil/CMakeFiles/wxutil.dir/window/TransientWindow.cpp.o [ 9%] Linking CXX shared library libwxutil.so [ 9%] Built target wxutil Scanning dependencies of target module [ 9%] Building CXX object libs/module/CMakeFiles/module.dir/ApplicationContextBase.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/CoreModule.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/DynamicLibrary.cpp.o [ 10%] Building CXX object libs/module/CMakeFiles/module.dir/StaticModule.cpp.o [ 10%] Linking CXX static library libmodule.a [ 10%] Built target module Scanning dependencies of target script [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/BrushInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/CameraInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/CommandSystemInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/DeclarationManagerInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/DialogInterface.cpp.o [ 10%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/EClassInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/EntityInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/FileSystemInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/FxManagerInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/GameInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/GridInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/LayerInterface.cpp.o [ 11%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/MapInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/MathInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/ModelInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/PatchInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/RadiantInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/SceneGraphInterface.cpp.o [ 12%] Building CXX object plugins/script/CMakeFiles/script.dir/interfaces/SelectionGroupInterface.cpp.o In file included from /home/chris/DarkRadiant/include/iselectiongroup.h:4, from /home/chris/DarkRadiant/plugins/script/interfaces/SelectionGroupInterface.h:7, from /home/chris/DarkRadiant/plugins/script/interfaces/SelectionGroupInterface.cpp:1: /home/chris/DarkRadiant/include/iselectable.h: In function ‘void Node_setSelected(const INodePtr&, bool)’: /home/chris/DarkRadiant/include/iselectable.h:31:37: error: ‘node_cast’ is not a member of ‘scene’ ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^~~~~~~~~ /home/chris/DarkRadiant/include/iselectable.h:31:58: error: expected primary-expression before ‘>’ token ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^ /home/chris/DarkRadiant/include/iselectable.h: In function ‘bool Node_isSelected(const INodePtr&)’: /home/chris/DarkRadiant/include/iselectable.h:41:37: error: ‘node_cast’ is not a member of ‘scene’ ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^~~~~~~~~ /home/chris/DarkRadiant/include/iselectable.h:41:58: error: expected primary-expression before ‘>’ token ISelectablePtr selectable = scene::node_cast<ISelectable>(node); ^ make[2]: *** [plugins/script/CMakeFiles/script.dir/build.make:297: plugins/script/CMakeFiles/script.dir/interfaces/SelectionGroupInterface.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:368: plugins/script/CMakeFiles/script.dir/all] Error 2 make: *** [Makefile:130: all] Error 2

Hi there, congratulations to the team for releasing version 2.08. Having watched this mod from the very beginning I am really amazed about the commitment this community still shows after all these years! I realized that there is now a 64 bit version of the game. Unfortunately when I try to run thedarkmod.x64 in my installation of Linux Mint 19.3 I get no sound. Any idea what might be the reason for this? The 32 bit version of the game works without a problem. When starting the game from a terminal I get some warning about "Couldn't load sound 'sound' using default". Here is the (slightly shortened) Terminal output:

I cannot compile TDM, I get this weird error that appears inside the standard library limits. The source code comes from the homepage. I tried to include and use limits in a small C++ program and I get no problems, so I have no idea how to continue. Can anybody help? Here is the log (out of topic, how can I disable the syntax coloring?): % g++ --version g++ (GCC) 4.8.2 20131219 (prerelease) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % uname -a Linux pendulum 3.12.6-1-ARCH #1 SMP PREEMPT Fri Dec 20 19:39:00 CET 2013 x86_64 GNU/Linux % scons -j2 BUILD_GAMEPAK=1 NO_GCH=0 BUILD=release --debug=explain "$@" scons: Reading SConscript files ... Loading build configuration from site.conf: BUILD_GAMEPAK='1' JOBS='1' NO_GCH='0' DEDICATED='0' SILENT='0' GL_HARDLINK='0' CC='gcc' BUILD_ROOT='build' ID_NOLANADDRESS='0' ID_MCHECK='2' TARGET_CORE='1' BUILD='release' TARGET_GAME='1' TARGET_MONO='0' BASEFLAGS='' CXX='g++' NOCURL='0' DEBUG_MEMORY='0' IDNET_HOST='' LIBC_MALLOC='1' ALSA='1' TARGET_DEMO='0' Command line: BUILD_GAMEPAK='1' Command line: NO_GCH='0' Command line: BUILD='release' scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/release/core/glimp build/release/core build/release/game scons: building `game/precompiled_game.h.gch' because it doesn't exist g++ -o game/precompiled_game.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/precompiled_game.h In file included from game/../idlib/../idlib/math/Math.h:24:0, from game/../idlib/../idlib/Heap.h:23, from game/../idlib/../idlib/Lib.h:157, from game/../idlib/precompiled.h:107, from game/precompiled_game.h:28: /usr/include/c++/4.8.2/limits:1405:35: error: template argument 1 is invalid struct numeric_limits<__int128> ^ /usr/include/c++/4.8.2/limits:1479:44: error: template argument 1 is invalid struct numeric_limits<unsigned __int128> ^ In file included from game/../idlib/../idlib/Heap.h:25:0, from game/../idlib/../idlib/Lib.h:157, from game/../idlib/precompiled.h:107, from game/precompiled_game.h:28: /usr/include/c++/4.8.2/cstdlib:178:10: error: expected unqualified-id before ‘__int128’ inline __int128 ^ In file included from game/../idlib/../game/Game_local.h:1305:0, from game/../idlib/precompiled.h:172, from game/precompiled_game.h:28: game/../idlib/../game/ai/AI.h:453:8: warning: extra qualification ‘idAI::’ on member ‘GetBaseAcuity’ [-fpermissive] float idAI::GetBaseAcuity(const char *type) const; // grayman #3552 ^ scons: Cannot explain why `build/release/game/game/randomizer/userintf.os' is being rebuilt: No previous build information found g++ -o build/release/game/game/randomizer/userintf.os -c -fPIC -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/randomizer/userintf.cpp scons: building `build/release/game/idlib/Base64.os' because it doesn't exist g++ -o build/release/game/idlib/Base64.os -c -fPIC -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Iidlib -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. idlib/Base64.cpp In file included from idlib/../idlib/math/Math.h:24:0, from idlib/../idlib/Heap.h:23, from idlib/../idlib/Lib.h:157, from idlib/precompiled.h:107, from idlib/Base64.cpp:2: /usr/include/c++/4.8.2/limits:1405:35: error: template argument 1 is invalid struct numeric_limits<__int128> ^ /usr/include/c++/4.8.2/limits:1479:44: error: template argument 1 is invalid struct numeric_limits<unsigned __int128> ^ In file included from idlib/../idlib/Heap.h:25:0, from idlib/../idlib/Lib.h:157, from idlib/precompiled.h:107, from idlib/Base64.cpp:2: /usr/include/c++/4.8.2/cstdlib:178:10: error: expected unqualified-id before ‘__int128’ inline __int128 ^ In file included from include/boost/filesystem/path_traits.hpp:23:0, from include/boost/filesystem/path.hpp:25, from include/boost/filesystem.hpp:16, from idlib/../idlib/Image.h:29, from idlib/../idlib/Lib.h:230, from idlib/precompiled.h:107, from idlib/Base64.cpp:2: include/boost/system/error_code.hpp:214:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ include/boost/system/error_code.hpp:215:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ include/boost/system/error_code.hpp:216:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ scons: *** [build/release/game/idlib/Base64.os] Error 1 scons: *** [game/precompiled_game.h.gch] Error 1 scons: building terminated because of errors. OSError: [Errno 2] No such file or directory: 'scons.signatures.dblite': File "/usr/lib/python2.7/site-packages/SCons/Script/Main.py", line 1344: _exec_main(parser, values) File "/usr/lib/python2.7/site-packages/SCons/Script/Main.py", line 1308: _main(parser) File "/usr/lib/python2.7/site-packages/SCons/Script/Main.py", line 1072: nodes = _build_targets(fs, options, targets, target_top) File "/usr/lib/python2.7/site-packages/SCons/Script/Main.py", line 1266: jobs.run(postfunc = jobs_postfunc) File "/usr/lib/python2.7/site-packages/SCons/Job.py", line 113: postfunc() File "/usr/lib/python2.7/site-packages/SCons/Script/Main.py", line 1263: SCons.SConsign.write() File "/usr/lib/python2.7/site-packages/SCons/SConsign.py", line 109: syncmethod() File "/usr/lib/python2.7/site-packages/SCons/dblite.py", line 127: self._os_unlink(self._file_name) Exception OSError: OSError(2, 'No such file or directory') in <bound method dblite.__del__ of <SCons.dblite.dblite object at 0x1b149d0>> ignored scons -j2 BUILD_GAMEPAK=1 NO_GCH=0 BUILD=release --debug=explain "$@" 12,59s user 1,88s system 62% cpu 23,085 total

Do you play on linux or windows?

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.

Seems like there are a rash of FUD videos about how "unstable" it is to use Linux This has all the ingredients of a targeted video meant to scare non-Linux users. 1) Starts by implying that Linux "might finally be ready for users". ( As if Linux having a good user experience is a "completely new development". ) 2) Talks about how a hot new Arch distro now can make it easy for users to install and play games. ( As if Synaptic Package Manager or Snap Store are impossible for standard PC users to understand ) 3) Encounters a wild buggy experience when installing a single App 4) Starts going into the weeds with all sort of jargon about distro issues and keeps waffling between "Linux good vs Linux bad". Anyone scared to try Linux will encounter item 3 and immediately look for a silver lining or happy ending but once they hear all the jargon and distro talk will just nope out. Ubuntu needs to wake up and start combating the FUD. For some reason, there is a big anti-Linux push. Maybe this has been stirred up because of SteamOS and it's presence on their Steam Deck game console is now a real threat and Windows 11 issues are driving folks to consider Linux instead.