Search the Community

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.

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.

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

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.

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.

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.

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.

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

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.

Hi, I just today started to play with DarkRadiant and struggled with some things. 1. When I type dmap and the name of my first map, I get the error: Cannot execute command dmap: Command not found? 2. DR crashes every time when I want to insert models. I go to create model and choose one from the tree and then it crashes. Prefabs don't make any crashes. Does someone has ideas what is going wrong here? Another question: Is there a possibility to scale a prefab? I inserted a lamp as prefeab in the map and can adjust the light radius, but not the model itself. Note: I use Arch Linux and installed the package from AUR: https://aur.archlinux.org/packages/darkradiant-git/

Hello Dark Mod team and community, long time listener, first time caller here... I recently ran into a problem with TDM 2.06 when I upgraded my Radeon drivers to 18.12.2. I can't remember what driver version I had before that (I don't upgrade too often) but I was able to run GLSL and soft shadows with the same hardware I have now, but the upgrade broke these shaders. Besides rolling back my drivers, I can work-around this problem by entering "r_useGLSL 0". I held off on reporting this problem because 19.1.1 was getting ready to release and I was hoping the new drivers would fix this, but sadly they have not. The way the shaders glitch out is interesting, walls are only lit by half and usually along a diagonal line or a curve that doesn't match the light that should be cast by the source and meshes are sometimes cut into quarters or lit in . Sometimes things aren't lit at all despite being directly in view of a light source, and look like their normals have been flipped inside-out or something. Normal maps and speculars are also not working. Besides being ugly, you can't always see where pools of light are being cast until you step into them and your light gem tells you you're visible, which inhibits gameplay. In every other respect, the game seems normal, but broken lighting in a Thief game is a problem, so I'm playing 2.06 in "2.05 mode" for the moment. Here are some examples: - from "Sir Talbot's Collateral" with GLSL on (broken) and same scene with GLSL off (old lighting working correctly) - "Heart of Lone Salvation", GLSL on and GLSL off (please pardon the missing book on the table) I'm using an AMD Radeon R9 390 Series, 8 gb of GDDR5 VRAM Intel Core i7 2600K at 3.4 GHz Windows 7 Home Premium 64 bit 16 GB of DDR3 physical memory On the Dark Mod wiki there's mention of creating a game profile with Surface Format Optimization turned off, but that did not alleviate the problem. Have you guys seen this before? I think the developer Stgatilov had a similar graphical problem and reported it here: http://forums.thedarkmod.com/topic/19752-tdm-205-weird-graphics-on-nvidia/ But his problem was on 2.05 and with Nvidia hardware, not AMD/ATI.

TDM 2.07 is primarily a stability release, aimed at improving several experimental features that were added in 2.06. Soft shadows now work better, for example, with fewer graphical glitches and a new Shadow Map mode that allows for contact hardening (and generally better performance). In addition to greater stability, there are a few new gameplay features, including a new frob helper that can be turned on in the Gameplay menu. Mantling low and medium-sized obstacles is now faster and smoother, and further mantling improvements are already in the works for the next update. There are a few new assets included in the update, including some new architectural module pieces, new chain models, and several trap prefabs (along with videos on how to set them up). For a longer list of changes and additions, see the 2.07 wiki page, or the full changelog. To update to this version, simply run tdm_update.exe in your darkmod folder. edit: Nbohr has posted a lengthy, illustrated description of the changes here: https://www.moddb.com/mods/the-dark-mod/news/the-dark-mod-207-stability-release

I'm finding the right mouse button to be very unpredictable at the moment. Sometimes nothing frobs, sometimes I have to hold to open doors, etc. However, there is one symptom which is very clear: lock picking doesn't work at all, instead I have to hold down Enter. I *think* this is new since updating to 2.07 (and the hot patch for lighting issues). Has anyone else seen anything like this?

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

When exporting from Blender to TDM in .lwo format, it's necessary to set the material names to textures/darkmod/,,,,something. If an object has a lot of textures it's going to be tedious to search the mtr files to get the right name. The same goes for applying textures to imported .lwo objects. I wrote this plugin to make that task much easier. Version 2.8.0 Download: Go to the GitHub page: https://github.com/RSoul82/Blender-TDM-Material-Manager Right click the .py file, then go to Save As and put it in some folder. (Or go to Clone or Download and save it as a zip file to your computer). The old version, for Blender 2.79, is here: https://github.com/RSoul82/Blender-TDM-Material-Manager/tree/Blender-2.79-archive (this is unlikely to be upgraded unless it causes serious problems) It'll be interesting to see how this is in the wild.

Hi! I'm a Thief-fan since almost 20 years now (times flies!) and have finally decided to treat myself this seemingly excellent game that is the Dark Mod. I've installed TDM on my mac using PlayOnMac, following the procedure outlined in the thorough step-by-step-guide found here: http://wiki.thedarkmod.com/index.php?title=Installer_and_Manual_Installation#Installing_TDM_on_Linux.2FMac_OS.2C_using_PlayonMac.2FPlayonLinux Still, when I try to launch TDM I get an error message saying TheDarkMod crashed. Any ideas on how to move forward from here? (I have btw not forgotten to install "mvsc100"). Thanks in advance, I am really looking forward to exploring the game!