Search the Community

Hi, guys! I just discovered the dark mod and found it fascinating but i'm running into a problem. The missions just don't appear as installed on the menu. The game recognizes the downloaded missions. I always choose to install, the game restarts but the "no missions installed" is always there. I always have to press the button again, but it will always go back to the menu just as i haven't installed it.

Thanks for this great project. I really enjoyed playing Thief 2 back in the day. I'm following the OS X installation instructions here: https://wiki.thedarkmod.com/index.php?title=Installer_and_Manual_Installation#Installing_TDM_on_Mac_OS.2C_version_2.05 When I get to step 11, i get this error message: -bash: ./tdm_update.macosx: Bad CPU type in executable I was wondering if anyone has encountered this error and has a workaround or solution. I really appreciate any assistance!

Hey, I just played my level on Briarwood Manor, and two things went wrong that never went wrong before on 2.07-08. There'a secret door in the library, that slides a book case and opens a wall. It's setup at player start. It opens fine, but it won't close the wall, but does close the book case. Never had this problem with this door before. Also, in the Stewards room. When he drops the key, you don't auto pick it up. You have to knock it around a bit before you can pick it up. Again, never had this before 1.09. Both these worked fine before and the map hasn't needed any updates for over a year.

But I don't know if it will run in this version of Linux. Do I need to install Ubuntu? Because I see it has been successfully installed and played there. As it is, I don't know enough about Linux to move the files and execute the files. And I don't know how to elevate my permissions. I know Ubuntu more than MX. I'm just looking for a not in the right direction. We have played every thief, and a multitude of Thief fan missions over the years. And we just discovered the DarkMod, and want to play it with every fiber of our being. I just need a word from the folks who know. I have been test running various versions of Linux for some time, Including latest Ubuntu. So I am by no means locked in or settled on MX Linux. Thank you so much! Thank you, thank you! Jim

We are proud to announce the release of The Dark Mod 2.09! https://www.thedarkmod.com/posts/the-dark-mod-2-09-has-been-released/ TDM 2.09 marks a new phase of performance improvements aimed lowering CPU overhead in the graphics engine. A whole new graphic backend has been created by Cabalistic which uses modern OpenGL features to eliminate the need for the CPU to constantly issue commands to allow the Graphic Processor to render scenes. This gives TDM some of the performance advantages of rendering using a low level API like Vulkan. Stgatilov has been very busy this release cycle. He has put heroic efforts into improving the way that TDM upgrades and hosting operate in addition to the vast improvements to TDM itself. (He also refactored the entire particle engine and created a link system to connect TDM to Dark Radiant.) A full changelog can be viewed here, but some highlights include: Better performance: A brand new Backend that uses UBO, Persistent Mapping, Bindless textures, and Multi-Draw has been added. “Frontend Acceleration” (Multi-Core job based rendering based on Doom 3 BFG) now works as expected. Normal Map compression now uses RGTC resulting in lower storage, VRAM requirements, and less artifacts ( load times should improve in future TDM versions when pre-compressed RGTC textures are added ) Background texture loading has improved. This should shorten load times and reload. Better visuals: A new Sharpening Filter has been added. It can make 70% Render Scale look almost like native resolution (more performance). ( It also cleans up some blurry textures for all Render Scales. ) Bumpmap lighting is smoother, so that lighting does not instantly flip to off when getting close to edges of occluded objects. Particle physics have been substantially improved for both accuracy and performance. Borderless Fullscreen works properly on Windows. Water and other GUI effects that did not respond to Gamma now brighten properly. AMD and Intel fixes have been added for SSAO rendering Better gameplay: Experimental Gamepad support has been added. Creep works in alway-run mode Better mapping: A new linking system allows The Dark Mod to act as a real-time preview of Dark Radiant The redesigned particles now have improved setup and configuration. Automated fixes have been created for “rotation hacked” models Prefabs have been seen numerous fixes and reorganization to make them easier to use Better Sound: Conversation and other sounds are no longer stopped by saving or going to main menu. EFX reverb has been added to “Mission 1: A New Job” Extinguished gas lamps are no longer noisy when doused New Assets: Dragofer, LDAsh, Kingsal, Bikerdude, Dram have all added substantial asset updates ranging from updated Werebeast animations, animation of the steam engine, fireflies and new furniture. More stable: A huge number of fragile code areas have been overhauled to either fix crashes or prevent likely crashes due to risk of divide by zero, uninitialized values, or dangling pointers (leftover settings) on entities and functions. We recommend that you upgrade using the new “tdm_installer” available here. Please be aware that old saved games will not be compatible with 2.09, so finish any missions you might be in the middle of first!

I've been playing TDM for a few years, but after my laptop updated itself to Windows 10 I couldn't open the game. I tried uninstalling it and then couldn't reinstall it. I can download the updater but when I go to run it I get this message. When I try to make the folders not read-only I uncheck the box but when I reopen the folder it is back to read-only. I am using the administrator account (I'm pretty sure) and changed the permissions on the folder but it hasn't worked yet. I'm not very tech savvy so any help would be appreciated. I really miss playing TDM!

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

I added the game to steam, and the overlay worked perfectly but after the 2.08 update, my cursor became a steam logo and i can't take screenshots, and pressing shift+tab to open the overlay makes puts a white box on top of the cursos where the steam logo was and the game stops working.

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.

Arch Linux, stable build, amdgpu drivers (rx480), GNOME-SHELL DE, primary display 1440p144hz, secondary display 4k 50hz. Upon launching the game, display settings are altered from join-displays to mirrored. Also, fullscreen is impossible when attempting to run the game with the 4k screen as the primary display.

Oh boy am I in Trouble...running Windows 7 64bit. I have the TDM running correctly and have been enjoying the brilliant fm's....so I thought I'd install the editor and take the plunge. I copied my TDM folder and renamed it so as not to muck up the original, I tested the copy and it worked fine on some fm's, I then downloaded the 64 bit Radient installer and installed it into the renamed folder...when I double click on the Radient editor I get "Dark Radient cant start MSVCR120.dll missing". I googled around and found a fix but I still get the error..VisualC++ thingy is uptodate and everything else is running quite happily, obviously I have done something wrong. Help please, Thank you.

TDM 2.08 Released! We are proud to announce the release of The Dark Mod 2.08! Long in development, many fixes related to Multi-Core, Uncapped FPS, and the 64-bit migration are now available. TDM 2.08 goes further with the process to modernize coding standards in TDM, replacing legacy OpenGL functions and ARB Assembly shaders with modern techniques. Mappers will be pleased to see many new quality assets as well as enhancements to rain, fog, skylight, AIs and visportal diagnostics. For the eye-candy crowd, new Bloom, 64-bit color mode, and SSAO options have been added! For Linux users, the project can now be compiled via CMake. A full changelog can be viewed here, but some highlights include: Better Visuals: Cabalistic has finally added the much requested SSAO feature to TDM. Using a method called Scalable Ambient Obscurance, now areas with flat ambient lighting come alive with new detail! He’s also implemented a new Bloom method, and brightness and gamma will no longer interfere with desktop brightness. Better AI: Grayman has refined the AI yet again, for instance ensuring that sitting and lying aren't thwarted by obstacles. Better Gameplay: The player’s ability to move and interact with the environment has been improved thanks to fixes to mantling as well as climbing ropes and ladders. Ragdolls are easier to handle and shouldering them is accompanied by an animation. Better Mapping: The mapper’s toolkit has seen several enhancements. A new X-ray surface and new spectrum spawnargs modify how objects are perceived. Rain is much less taxing and uses static collision detection to limit its fall. New visportal diagnostics make it easier than ever to track down notorious internal leaks. Better Performance: The dev team has as always been hard at work making improvements to performance and laying the groundwork for even more improvements in the future. Multi-Core’s stability has been enhanced and is no longer listed as an “Experimental” setting. New Assets: Many quality textures and models were added by both Team members and community contributors. Especially of note is the inclusion of Kingsal’s manbeasts and Springheel’s new zombies, and expect to catch glimpses of the werebeast. If you are a mission author, please take a look here. New Sounds: The player’s movement is now accompanied by new sounds when mantling, swimming and sliding down ropes and ladders. To update, simply run the tdm_update.exe file in your darkmod folder. Please be aware that old saved games will not be compatible with 2.08, so finish any missions you might be in the middle of first!

I keep getting this error message saying that "Microsoft Visual C++ redistributable package failed to install. You have to install it yourself in order to run the game. Run vcredist_x86.exe and vcredist_x64.exe in game directory and make sure installation completes successfully. I already have the latest version of the package from when I update Windows 10 from Windows update. Why is this happening to me? How do I fix it to make it go away?

Hello, I am using Liinux and TDM in Version 2.05. When I try to update TDM I get the following output: cd /usr/share/games/darkmod; ./tdm_update.linux bash: cd: /usr/share/games/darkmod: Datei oder Verzeichnis nicht gefunden TDM Updater v0.66 (c) 2009-2017 by tels & greebo. Part of The Dark Mod (http://www.thedarkmod.com). ---------------------------------------------------------------------------- Initialising... Done. ---------------------------------------------------------------------------- Cleaning up previous update session... Done. ---------------------------------------------------------------------------- Downloading mirror information... Done downloading mirrors. Found 5 mirrors. ---------------------------------------------------------------------------- Downloading CRC file... Downloading from Mirror darkmod-alt02.taaaki.za.net: crc_info.txt [=========================] 100.0% at 0 bytes/sec ---------------------------------------------------------------------------- Downloading version info file... Downloading from Mirror darkmod-alt02.taaaki.za.net: tdm_version_info.txt [=========================] 100.0% at 0 bytes/sec Done downloading versions. Newest version is 2.07. ---------------------------------------------------------------------------- Trying to match local files to version definitions... [=========================] 100.0% File: Done comparing local files: no luck, PK4 files do not match. ---------------------------------------------------------------------------- Comparing local files to server definitions... [=========================] 100.0% File: Done comparing local files to server definitions. A new updater is available: 1 file needs to be downloaded (size: 670 kB). ---------------------------------------------------------------------------- Downloading TDM Update application... Downloading from Mirror fidcal.com: tdm_update_linux.zip [=========================] 100.0% at 375 kB/sec Done downloading updater - will restart the application. Relaunching tdm_update via shell script /home/stefan/the dark mod/tdm_update_updater.sh ---------------------------------------------------------------------------- Your TDM installation is up to date. sh: 1: /home/stefan/the: not found So the version stays the same. What can I do to update to 2.07? I hope someone can help.

When I use the clipper, a line is visible in the place where the clipping took place, as you can see in the attached image. What am I doing wrong? I tried different textures but the line is always visible, as if there was a little space there, which I don't know how to fill. I watched multiple tutorial videos but they don't get this problem when clipping, so I'm wondering if maybe there's an option somewhere? Any input would be greatly appreciated.

My main Win7 PC crashed out. I suspect a bad partition. I've got it working somewhat but it's likely to crash and need rebooting regularly depending what I'm doing. Two programs won't run at all, one being my email program. I've managed to rescue a backup mailbox only two days old and copied it to my old Win XP machine in the other room. Not yet tried to run it there until I've figured out some more stuff. Because I mainly use my PSP for gaming, I've been considering getting a mini pc for general use but not easy to get Win7 (Win8 or 10 I don't want!) There is a lot of confusion about needing a product key (which of course I won't have if I buy a new mini pc without an OS!) So, sick of M$soft, I'm now considering Linux. After learning that Ubuntu provides an image file I can download and burn to DVD and try it from there I did so (on my good XP machine) but on booting the DVD I get a message 'Try' or 'Install'. At that point I see a blank desktop with a taskbar at the top and a couple of items on it like shutdown. If I click 'Try' I see two icons appear for a fraction of a second at top left which then disappear. Then over the next few minutes I hear the drive working and see a couple of blank coloured screens. Finally a blank pale white(grey?) screen. I have a working mouse pointer but nothing else. I've tried right click, left click all over the screen. Tried various keys but nothing, no icons, no taskbar, nothing. If I click near the left or top borders I sometimes hear the drive working and a circular pointer suggesting it's working but that times out. I've also sometimes seen the pointer change to what looks like the text editing pointer. After 30 minutes I gave up. Had to pull the plug. On rebooting I got the same. Rebooting without the disc in I get my XP back (Phew! I was worried it had wiped it!) Any ideas? It should run from the DVD so I can try it out first, But if I should choose the install option instead, where will it install? I've got plenty of space but will it ask where to install? Will it wipe over my XP install or what?Will it create a new bootable partition? I only really want to install if and when I get a new mini pc. Any other Linux versions that let you download an iso image? I just want to try Linux! PS: With no email working yet, I'll have to remember to come back here a few times each day to see if any answers so don't hold your breath.

This is the third time I've fired up my computer to find that the executable for running the 64bit version of DarkMod has been deleted. I've had to re-install the whole game in order to get that executable back, and in the process of coarse I lose my saves. It doesn't happen right away. This last time I was able to play for a few weeks before TheDarkMod64.exe vanished. Has anyone else suffered this problem ? I'm thinking it might be a Windows Defender decision but I have no way of knowing.

I have more than one problem here that needs addressing, but hopefully one solution will help the others. I will start at the beginning. For some reason "TheDarkModx64.exe" disappeared on me today. I was playing the game yesterday without issue. A shortcut to the game is pinned to the taskbar and I was informed that the file the shortcut was pointing to no longer existed. Nevertheless I did a search throughout my computer for the executable without success. So I thought I might as well upgrade to 2.07 and maybe that would bring back "TheDarModx64.exe". The installation wouldn't complete however because "Microsoft Visual C++ redistributable package failed to install." I was prompted to run vcredist_x86.exe from the game directory. That failed as well because..... "Another version of this product is already installed." I finally decided to reinstall the game in a different folder but lost all my fan missions & saves (they are there in the original folder). 1. Does upgrading to 2.07 make all the saves from 2.06 unplayable?? 2. "TheDarkModx64.exe" shows up in my new DarkMod folder. Can I copy/paste to my old folder?? 3. My old folder (with all the saves in the "fms" folder) will play if I run TheDarkMod.exe instead of TheDarkModx64.exe. But the saves won't load. Is there a difference (other than running 64bit) between the two executables? I copied "fms folder" over from the old folder to the new folder...same problem (saves won't load) I copied "TheDarModx64.exe" from the fresh install to the old folder with no change. So if the Saves from 2.06 don't survive the upgrade, then there's not much I can do except reinstall 2.06 if I can find that version anywhere. Probably digging myself deeper into a hole here Thx in advance for any advise.

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.

The #metoo movement went with a credible "testimony" against one of my favorite video game music composers - Jeremy Soule. I always made it a rule for myself not judge of an artist/writer/composer by his personality but just to look at his professional work. Don't know if I can be indifferent to this. Would you like to listen to the music of a rapist henceforth? http://www.nathalielawhead.com/candybox/calling-out