Search the Community

Overnight my mouse has stopped working - ie moving my viewpoint - when I'm inside a TDM mission. It previously worked fine in my current mission. I tried running a different mission, but same problem. The mouse works fine when I'm in the Main Menu, but not in the game itself. I'm running TDM 2.09, and I just ran 'tdm_update' just in case. Any advice please? That would be much appreciated.

There have been several occurrences in the last week or two that have underlined the need for a list of missions that showcase TDM in its best light. ------------------------------------------------------------------------------------------------------ Posted Results: ---------------------------------------------------------------------------------------------------------------------------------------- (Extended discussion here: http://forums.thedar...f-tdm-missions/) I was hoping a non-mapper might take on the process of running the thread and tallying the results, but since everything is public I decided to just go ahead and get the ball rolling. DIRECTIONS ========== Write down the names of the FIVE missions that you think should be considered "The Best TDM Missions". If someone could only play 5 TDM missions, which 5 should they be? At the end of the week, I will compile the responses. The five missions that get the most recommendations will be labelled "editor's picks" or something like that. Do not rank your choices. List 5 in any order you like. ========================================== To keep this clean, anything other than recommendations or clarification questions will be removed to a different thread.

During console "map", I get a list of TDM sound files, like "animal_flies_loop01.wav" with "WARNING: Couldn't load..." messages. Those sounds do indeed appear to be not playing (I only checked a few). This was a build that worked under 2.09, but had this problem when copied to my 2.10 environment. Deleting the .cm, .proc, .aas* files under 2.10 and redoing the dmap there did not fix it. Are you seeing this too?

Lastest dev build (dev16358-9588): UNABLE TO INITIALIZE OPENGL The same for the Intel AND the Nvidia GPUs. Problem with the ICD?

How about adding TDM to nexus mods, for more exposure? Info: https://help.nexusmods.com/article/104-how-can-i-add-a-new-game-to-nexus-mods

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.

This has bugged me for a number of years, how to get a door that's on the horizontal diagonal to open correctly. I would appreciate any ideas or help, as I have been banging my head against this for the last hour or so. test.map.txt

Since I like TDM movement model quite much, I've spent some time on figuring out relationships between player abilities (running, jumping, crouching, mantling) and object placement. In short, you can design pathways in your map to feel more dynamic and pleasant to traverse. This short section shows that player movement model is smooth and snappy enough to allow for speedrun or time trial sections. It looks a bit abstract, as most of the environment pieces weren't replaced by models, but that was the plan. Let's pretend most of the white ledges are pipes Also feel free to use this video if anyone at TTLG starts talking things like "TDM is too clunky", "Thief movement is superior", etc.

What plans are in store for TDM next year in 2020 such as new features or anything in between? I do know new fan missions are always releasing periodically. Just want to know what new things we can expect for the future of TDM going into the new year.

There's some sort of problem with the TDM updater whereby it won't create a proper 2.07 installation. Being on a slow Internet connection, my TDM installation/update procedure has always involved downloading just the latest update zip file (currently, 'tdm_update_2.06_to_2.07.zip') from the ModDB site and making that available to the updater locally, to avoid unreliable, slow downloads during the actual update. I followed the same procedure that I've always (successfully) done in the past: extract the huge, 2.3-GB 'THEDARKMODVersion2.0-StandaloneRelease.zip' file (downloaded once from ModDB and re-used many times over the years) change the permissions on all the PK4 files to be write-able (so that the updater can alter the content within, as needed) delete the existing, obsolete (2013-era), read-only 'tdm_update.log' file (which shouldn't be in the zip file to begin with) put a copy of all the 'tdm_update_2.0{x}_to_2.0{x+1}.zip' files amassed to date into that extracted directory download the latest version of the TDM updater app (from the TDM website) run the updater, with the options '--keep-update-packages --noselfupdate' On the 1st run, it proceeds in what appears to be normal fashion. There's no obvious indication that anything has gone amok. However, if you run the game, it comes up with the main menu showing "TDM 2.06", not the expected "TDM 2.07". Here's the TDM updater log file for this 1st run: tdm_update--run-1.log.txt Some analysis of the directory content and the updater's log file seems to indicate that the installation only made it to 2.06! As for the 'tdm_update_2.06_to_2.07.zip' file, I've verified the integrity ('zip -T'). I've also verified the filesize and checksum against the updater-downloaded 'tdm_version_info.txt' file: [UpdatePackage from 2.06 to 2.07] crc = 159677cb filesize = 427644498 package = tdm_update_2.06_to_2.07.zipSo I don't think there's anything wrong with that particular file. If I compare what the updater created as a "2.07" installation with an old, virgin 2.06 installation of mine, the only files that are different are ones that you'd expect to be: 'crc_info.txt', 'tdm_mirrors.txt', 'tdm_update.log', and 'tdm_version_info.txt'. If I run the updater a 2nd time (and all subsequent times) with the same options, it essentially does this: Applying differential update package... [=========================] 100.0% Adding: ExtLibs.dll [=========================] 100.0% Adding: ExtLibsx64.dll [=========================] 100.0% Adding: TheDarkModx64.exe [=========================] 100.0% Adding: thedarkmod.x64 [=========================] 100.0% Adding: vcredist_x64.exe [=========================] 100.0% Adding: vcredist_x86.exe [=========================] 100.0% Replacing: AUTHORS.txt [=========================] 100.0% Replacing: TheDarkMod.exe [=========================] 100.0% Replacing: tdm_update.exe [=========================] 100.0% Replacing: tdm_update.linux [=========================] 100.0% Replacing: thedarkmod.x86 [=========================] 100.0% File: Done applying the differential update.Due to website file upload limitations, the TDM updater log file for this 2nd run will be attached to a subsequent post. The updater log files on that 2nd and all subsequent runs are essentially identical, just with different timestamps and potentially use of a different mirror site. That's the repeatable scenario, the "crux of the matter", if you will. FWIW, I also dug more deeply into the problem. What I describe from here on is less thoroughly documented, but I'll mention what I did, in case it helps.... I tried removing all of the update zip files, hoping it would force the updater to update what is effectively a 2.06 installation but via a slow, painful download of that 408-MB 'tdm_update_2.06_to_2.07.zip'. But instead, it inexplicably wanted to download the 235-MB 'tdm_update_2.05_to_2.06.zip' file, so I aborted the update. Taking a different tack, I dug into the updater source code a bit and noticed this curious-looking snippet in '.../tdm_update/libtdm_update/Updater/UpdateController.cpp': //#4529 stgatilov: Since differential update does not uncompress unchanged OGG/ROQ files, //The hashes of pk4 files are now different from the ones on the server. //That's why we exit right away to avoid redoing the same differential update and redownloading the unchanged data. if (info.fromVersion == "2.05" && info.toVersion == "2.06") { TryToProceedTo(PostUpdateCleanup); break; }I played around with various changes to that code (both bumping the 2 version numbers and outright disabling the whole block), but to no avail. Although I'm running Linux (64-bit Slackware 14.2), I don't immediately see any reason why this would be OS-specific. This issue sounds different from the problem grayman had (running Windows), but I did get an "infinite updater loop" scenario when I hacked that code mentioned above, so maybe there's some correlation. I also noticed during some debugging that the installation I had was not being correctly recognized by the updater app as a valid 2.06 installation. When I looked into the updater's console output and log file, it seemed that every file about which the installer reported "SIZE MISMATCH" was one of the PK4 files that had embedded OGG files, although I did not check every case. I'm simply not able to figure out what's going on here, despite much effort, so I have to "punt" before my head explodes. Any input on this matter would be very much appreciated!

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.

Asus i5 zenbook with MX150. Opened my WIP in the laptop to check and compare framerates against my i5 desktop with geforce 1060. Since I'm using the dev build 16269-9407 on the desktop, used the same build on the laptop and got "Unable to initialize OpenGL" screen. Backtracked thru' the dev builds and found the last working version was dev16225-9284, which loads the game fine. Problem starts with dev16238-9330 and the two newer versions. No similar problem on the desktop. (and.... WIP framerates on the laptop will give some people heart attacks. Tho' I find it still playable - TDM isn't deathmatch - and it looks very good on that little machine.)

Hi all, I've created a new Github organisation to host any sort of assets people maybe want to share: https://github.com/thedarkmodcommunity A Github 'organisation' is a collection of separate git repositories that can store code snippets, assets (model files, textures, sound files, etc) or documentation. I know there is debate over the suitability of Git for binary files, but for small files and most things you'd use in a FM, it works totally fine. FYI the maximum file size for upload is 100 MB, and the maximum repository size is 10 GB. You don't need to know anything about Git to browse the repositories, or download files. You just need to be able to use a browser. I've created a repository for script snippets: https://github.com/thedarkmodcommunity/scripts and one for models: https://github.com/thedarkmodcommunity/models and one for prefabs: https://github.com/thedarkmodcommunity/prefabs For models, it even has a built-in 3D viewer (just need to provide an .stl file). It won't show textures unfortunately, but you can switch between solid, wireframe and 'surface angle' views. Example: https://github.com/thedarkmodcommunity/models/blob/main/darkmod/lights/non-extinguishable/streetlamps/streetlamp_with_signs/lamp_sign.stl The models and prefabs are accompanied by a .jpeg preview image that is displayed automatically in the readme file. Example: https://github.com/thedarkmodcommunity/models/tree/main/darkmod/lights/non-extinguishable/streetlamps/streetlamp_with_signs I did this to help solve the following problems: frustration with trying to locate existing code (searching through other FMs, searching the forums, having to ask) frustration with the frequently out-of-date wiki. There is some really great stuff on there but I would just like to be able to contribute and share in a central location without having to ask permission, or ask someone else to do it. hopefully people won't have to keep asking the same questions over and over again - they can just browse the repositories make updates easier - anyone with a Github account can create a pull request, or just send an admin the files they want added TO BE CLEAR: this is NOT intended to replace SVN, or the Wiki, or the forums, but just to provide a central place for sharing assets, primarily for mappers want to easily share what they've done, or borrow existing stuff without having to reinvent the wheel. So, if anyone wants to donate files, script snippets, whatever, please get in touch by replying, sending me a DM (here or on Discord), or by the 'normal' way and just create a pull request. Also, if anyone else want to volunteer to help maintain this, please get in touch as well. These people would just need to be able to create repositories (if needed), or review/merge pull requests.

How do I run TDM in windowed mode...It won't change when I set Fullscreen to "No"... This is a big deal for me when I map and jump between DarkRadiant and TDM...

Hello guys :-D I've installed Kubuntu the latest 18.04, and KDE rocks (far far far better then Gnome, IMHO, Plasma evolved incredibly). The problem is: I cannot run my lovely TDM :-( If I launch it from shell ("./thedarkmod.x86") as I was doing in the past versions of Ubuntu, I receive this message: error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory I tried with "apt search" to find out about this library and: libxext-dev/bionic 2:1.3.3-1 amd64 X11 miscellaneous extensions library (development headers) libxext-doc/bionic,bionic 2:1.3.3-1 all X11 miscellaneous extensions library (documentation) libxext6/bionic,now 2:1.3.3-1 amd64 [installato] X11 miscellaneous extension library libxext6-dbg/bionic 2:1.3.3-1 amd64 X11 miscellaneous extensions library (debug package) libxmu-dev/bionic 2:1.1.2-2 amd64 X11 miscellaneous utility library (development headers) libxmu6/bionic,now 2:1.1.2-2 amd64 [installato] X11 miscellaneous utility library libxmu6-dbg/bionic 2:1.1.2-2 amd64 X11 miscellaneous utility library (debug package) libxmuu-dev/bionic 2:1.1.2-2 amd64 X11 miscellaneous micro-utility library (development headers) libxmuu1/bionic,now 2:1.1.2-2 amd64 [installato] X11 miscellaneous micro-utility library libxmuu1-dbg/bionic 2:1.1.2-2 amd64 X11 miscellaneous micro-utility library (debug package) So the "libxext6" is installed. Any suggestions to solve this?

Recently, about a month ago, @demagogue mentioned the following in another discussion: While we're at it, someone really needs to write an official history of the Empire and a lot of associated fanfic to give our world backstory. And someone ought to make an art book with screenshots across all our FMs and some story, as if it were like one of those travel photo books. Something people put on their coffee table for discussion and just to flip through for fun, or in your case actually make the things. I see the idea you're talking about as something along those lines. I even promised demagogue I might look into it in the future. All of this got me thinking... We know The Dark Mod does not have a strict canon, per se. There's Bridgeport and The Empire, a few other cities, there's notes on what technology, society and the fantastical elements of this setting are, what the various typical "factions" are and how they vary greatly, what the atmosphere and tone is like, and so on and so forth. However, the rest of the things are far more nebulous and are generally down to what an individual player or fan of TDM is willing to accept as potential canon. We had the references to cities (Braeden) or minor setting elements (the mandrasola drug, etc.) throghout multiple missions by unrelated authors, and those are just the simplest of examples. In short, what constitutes as TDM canon, beyond those fairly official basics, is quite maleable. With all of the above in mind, and taking demagogue's ideas into account, I think we could compile a rough, loose history of the overall setting. It doesn't need to be obsessively filled with details, but we could give people some vague idea of what happened in the last two thousand or so years before what we generally portray as the "present day" of the TDM setting. I think we already have plenty of interesting source material to work with, if our goal is to create a rough timeline/outline of The Empire's history, the Builder church's history, and hints at what the history of the world outside of The Empire has been like (also counting with possibly biased accounts, in-universe). Now, speaking about that source material, what do I actually consider as source material ? Technically, every mission or nearly every mission made for TDM could be potentially considered source material. However, I am a little bit more picky about this. I think the closest we have to an established, "hard canon" for the game's universe, is a lot of the above-mentioned source material, and that occurs primarily in two places: In the two or three official missions that come with the basic TDM install (Training Mission, A New Job, The Tears of St Lucia), and in the main Universe articles on the TDM wiki. These are going to be my primary source for compiling the history, chronologically and otherwise. In addition to the official-as-official-gets missions and official universe notes, I am also willing to include stuff from all fan missions, if it expands the history of the setting in interesting, but reasonable ways. If the premise of a mission clearly doesn't fit the rest of the setting directly or is quite jokey, then I won't consider it a reasonable enough source for a potential addition to "canon". Why would demagogue suggest we should compile such a more detailed background history ? Personally, while I don't mind the idea, I am also fine with keeping things as they currently are. At the same time, I have noticed the number of people who come to the forums, clamouring things like "Where's the sprawling story campaign ? Where's the sprawling background story of the setting ?". Less of the latter thankfully, more of the former, for understandable reasons. Still, it seems that a lot of newcomers to TDM, especially those with pre-conceived notions from their time playing Thief (or other fantasy games), seem to want more from the overall setting than just the missions and mission series we have. Honestly, I'm torn on this. I've always been an elliptical storytelling style guy. Less is more. A hint here, a hint there, a throw-away comment there... Some games try to overdo it with super-detailed lore and the results can be... questionable and grating. Part of why I'd prefer that, if we do compile more of a broadly accepted "canon" for TDM's setting, then it should still be accepted in that "broad" way. I.e. it is soft and maleable enough that it does not tie mission-maker's hands, with regards to missions and stories set in the past, present and potential future of the TDM setting. A lot of players think they know what they want if they want a detailed setting, but more often that not, it just ends up with things being overexplained and losing their "charm" and a reasonable degree of mystique. After all, even die-hard Thief fans should acknowledge one thing: Thief didn't try to explain everything. Far from it ! The entire trilogy was very fond of elliptical storytelling, with hinted-at stuff and loads of unexplained stuff and references. I think TDM should keep with that, even if we potentially expand the "hard canon" parts of TDM's canon. Not stuff like "in this or that year, William Steele was born", but certainly stuff like "from the 4th to 7th century of its existence, the Empire was ruled by this or that dynasty, in a unique tetrarchic set-up", and similar.

Hello fellow Taffers, I haven‘t really been active on the DarkMod Forums but I’m enjoying the mod since its early days when it just came out. (I even bought doom 3 to make it run ) Some of you might know me from the inofficial Thief Podcast “Inside at Last” (check it out here or search for it on you favorite podcast app or spotify) and that’s the reason I’m posting here. I’m not so familiar with the DarkMod scene but I’m sure you guys can help me. I want to do an episode about the DarkMod and for that I need guests that are experts on that topic. Of course it would be great to have one of the original creators of TDM but also it would be great to have one or two experienced authors so we can discuss the roots and of course every aspect that TDM gives us from gameplay, technology, Original Thief comparison/pros/cons…you get the idea. So please guys let me know who would like to join our podcast as a guest or maybe you can help to get in contact with people you think are esencial. I once had contact with one of the people that are in charge of TDM but my taffing email notifications stopped the conversation before there really was any. I’d be very grateful to hear your opinions on that and to everyone who would like to participate/help making it happen. Thank you taffers! Here is an example of how an episode "looks" like: YoutubeChannel You can also add me on discord: Supremcee#7159 and sorry if I maybe posted it to the wrong topic, but it seemed like the best choice

Heya all and thanks for this great mod! I would like to know how you can run TDM on FreeBSD, as I saw a screenshot on FreeBSD in this forum. My version is 10.1-Release Linuxemulator is running, the installation went well. But I get the message error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directorywhen I start TDM. The libpng installed from the ports is already on v14. #Edit: the already installed libpng v14 is installed for the freebsd-system, you need the libs (v12) especially for the linuxemulator too! Read next post! On Linux it's running just fine!

A while now I have the problem that the TDM in-game mission downloader crashes during downloads. Usually if I download 1 mission it's ok, but if I que downloads there is a chance of crashing. I waited for the database upgrade, to see if anything changed. I cannot pinpoint where it goes wrong. Is there a logfile somewhere where you can see where it chokes and then crashes?

The latest version of TDM forces full screen when playing at 4x3 resolutions, it seems to force your native desktop display. Problem is not only does this cause severe lag on my laptop, but tbh I actually much prefer having borders at the left/right side of the screen. I was pretty dissapointed when this was removed. Any plans to reimplement/patch the menu config actually responding to your desired resolution settings? I'm sure I'm not alone in disliking this strange design decision.

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

Obviously, the main way to contribute to TDM is to contribute work and expertise. FMs, tech improvements, every little helps... I've been thinking about whether, besides general TDM trailers, previews, FM briefings, wallpapers, promo images, and so on and so forth, we could drum up a little amount of extra publicity for TDM via more physically tangible, but financially permissible promotional materials. As I note in the title of this thread, how about using a few select paper models, each with a The Dark Mod theme (and the associated stylistics), as something of a fan keepsake new or old fans of our freeware game could build and keep ? I'm under no illussions it would be amazing or anything. However, as a bit of a feelie, done in free time as simple promotion by some members of what is essentially a hobbyist freeware dev team, I think it would be an aptly humble, but still original bit of extra promotion. Everyone expects wallpapers, screenshots, promo videos, and so on, but some papercraft promo could help add a little bit of different flair to that more conventional promotion we already have covered. You might think "Okay, a few people will build those paper models, but how effective could this promo be, anyway ?". Well, as much as I don't have any illussions... Imagine if someone puts a building from Bridgeport paper model on their desk, next to their computer, at their own apartment/house or at their dorm room, and someone eventually asks: "Nice ! Is that a real building ? What's that from ?". The owner, who also plays TDM in their free time and is already a fan, can say: "Well, it's from this and that stealth game with this and that style setting. Want to see it ?" Then he can show the curious guy or gal this site, a trailer or two, start up the game and show some gameplay from a mission or two, the training mission... Who knows, maybe he'll get that other person interested, maybe even hooked. And it all starts with a simple paper model of some building from the TDM world. Now, playing the game in front of them could achieve a similar result. Having a TDM wallpaper as the background on the screen, or being caught watching a trailer video or Let's Play video of TDM could achieve similar results too. In the end, though, those things are wholly digital. They're not as immediate and tangible in the same manner as a paper model can be. Yes, at the end of the day, it's just card paper with textured surfaces printed on one side, skillfully cut out, assembled and glued together. But it's still a physical object, giving you more of a 3D feel than just a 2D screen (and not necessitating any VR equipment for greater immersion, beyond the limitations of that on-screen imagery). Now, concerning what the paper models would encompass, how they'd be constructed and look, I think we have to be realistic about it: Most people can bother with a paper model of a simple enough building or object, but they won't be assembling detailed paper models of, e.g. a City Watch guard. Ergo, the TDM promotional paper models we could have should focus on two areas: 1.) architecture from the setting, primarily that of The City and other urban environments (clocktower, medieval townhouses, some castle or manor house, etc., you name it); 2.) gadgets and items carried by the player character thieves in the game (a paper model of a mine or even a flashbomb, a paper model of a potion bottle or of the small hooded lantern, etc.). The surface and details should be based on textures we assign to their models directly in the game. This is obvious in the case of the gadgets and items. In the case of buildings, they could either recreate an iconic building from some FM's scenery, or they could just as easily depict a generic building, but with the same combination of building textures as you see on buildings in TDM missions. The same stone textures on the outer walls, the typical late-medieval/early modern style windows, with their metal grills and glass panes, etc. Having the paper models designed and textured in such a way that they'd reflect TDM's predominantly night time setting (including dimly lit windows on buildings) would be a pretty cool move, IMHO. It would also be accurate to the atmosphere of the game. Distribution method... Could be available for download among the promo materials section on the site, either in .pdf format or some image format (.jpg or .png). Should I take a stab at designing some basic model concepts in my free time, if I'm ever bored ? Just as a test whether we could create TDM paper models in the first place. I think there is some merit to using paper models as an inexpensive and entirely ancilliary, but still useful promotional item. Especially for a freeware labour of love like this one, tirelessly being worked on for over 16 years. Sixteen years of this much patient fan devotion is nothing to sneeze at.

Hello has anybody tried to compile TDM on a raspberry 3?