Search the Community

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

No, too many variables involved: external app, controls configuration, game settings... We are talking Master Thievery Level here, most of the taffers will get nowhere.

Hi, I've tried to install the latest version of TDM four times now (no previous installation), each time I get the same error: ERROR: Unexpected CURL error 56 on URL The urls seem to change (examples are http://darkmod.taaki.za.net/release/zipsync/release/release200/tdm_textures_metal01.pk4, /tdm_models02.pk4, /tdm_textures_carpet01.pk4) but the installation always fails around 20% of the way through. Am I doing something wrong? I tried the default mirror and the German mirror (also version 211 just in case). I'm using Windows 10 (64 bit) and don't seem to be having any internet issues that would cause the error. Any help would be appreciated!

I had this discussion a lot with my Bloodlines Unofficial Patch and honestly, nobody really knows what an unofficial patch can or should do, because a) it's unofficial and b) many developers add or change features with their patches (just look at CP2077 2.0 or TDM itself). I kept the name because it's similar to the other patches I do and does not stray as far away from the original game as e.g. Snatcher's Mod. Also to me, being able to extinguish candle flames but not oil flames, or enemies getting magically immune just by noticing the player are bugs. If not of the pure computer gameplay kind, then certainly of the consistent world building kind ;).

It occurred to me that, by now, this package goes well beyond mere bugfixes by including a range of gameplay changes (i.e. adding the ability to frob-extinguish oil candles, which isn't a bug that was patched). Maybe players would have a better idea of what this package does if it had a more fitting name, similar to how Snatcher calls his work a modpack? In other communities the term "unofficial patch" is typically associated with collections of community fixes to bugs that exist in the core game and were never addressed by the devs. Most players would therefore expect an "unofficial patch" to provide them the same experience as originally intended by the devs, but without technical problems.

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

Sorry for digging this out, but, one thing I always wondered: Shouldn't a gamma value of 1 in Dark Mod give you the best experience when you're using a monitor with a gamma value close to 2.2 (which I think is the optimum in terms of realistic colour reproduction)? I have a monitor with very good out of the box colour reproduction, and almost ideal gamma. Yet I have to turn down the in-game gamma to about 0.9 to get a good result. I must say though that I prefer it darker than what the average player probably has, so, that might be the problem here. Still, I usually have very good result leaving the gamma on default setting in most games, which is probably calibrated towards monitors which display ideal gamma.

You can't softlock by getting stuck in this game, open console type "noclip" and fly to wherever you need to. But yeah, it is a bug.

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm proud to release my first FM: "The Terrible Old Man", an adaptation of H.P. Lovecraft's short story of the same name. This is a short, 30-45 minute mission in which you are the getaway driver in a team of three small-time thieves. You and your associates were fortunate enough to overhear rumors of a famously wealthy and frail old man, but things change when your cohorts do not return from what is supposed to be their easiest and most lucrative job. Now it's up to you to brave the old man's house and find your associates. Download: The in-game mission downloader TDM Website's Mission Page Dropbox Special Thanks: The kind beta testers: Cambridge Spy, stgatilov, xlm, wesp5, nbohr1more, and Dragofer. peter_spy and Dragofer for answering my endless barrage of editor questions while learning DR. The TDM Discord for their warm welcome. Ending stinger courtesy of Zapsplat. Content Warnings: Enjoy!

"Ignorant" opinion: I doubt that 99,9% of the general population would notice the difference in game, so, this is a bit of a geeked out discussion. Also, if there are some significant downsides which can't be overcome, then I'm always for the solution which offers more and causes less trouble, regardless whether or not it looks 0.001% worse.

And those pics that Daft Mugi posted do show the problem with TDM maps, but I also have to say, that is a problem with TDM shadow maps, not with maps in general, I never seen such ugly issues in Stalker for example or Call of Juarez and many other games. Perhaps those shadow maps issues arise from people not thinking of shadow maps at all, when creating their lights, shadow maps do require a little more tweaking to look good, specially at grazing angles, because they are literally textures, so perhaps moving the lights a little solves those problems or even increasing the shadow map res. Just think about this, if shadow maps where that ugly, the gaming industry would never deprecate stencil shadows and we would still be seeing a ton of games using them, but is totally the contrary, games with stencil shadows, are the minority, even idSoftware removed them, I think since Rage (i'm not totally sure about Rage...) and up (besides obviously Doom 3 BFG). For example: Wolfenstein II Dishonored 2 Evil within 2 (this particular shot is impossible with stencil shadows, because of the blood that is a particle effect with alpha) etc. For obvious reasons TDM fans have a good opinion of stencil shadows and I comprehend that, they do look very good, TDM and Wolfenstein 2009 are the games with the best soft stencil shadows that I haver seen, but maps can also look good, if given the chance and used to their full potencial. another game with good stencil soft shadows Thou tree shadows on this game seem to use something else or literally stencil shadows because sometimes they look like a blob on the floor instead of seeing the individual leaf.

Losing the option for stencil shadows would be extremely sad. TDM has the best stencil shadows implementation I've ever seen, and they look far better than shadow maps. They also perform wonderfully. Stencil shadows not supporting shadows on translucent surfaces is a bummer, but that's a fine tradeoff. Personally, I'd rather not see alpha-tested shadow occluders, because they look awful and are distracting. Shadow maps in general look bad and pixelated -- quite immersion breaking. Another issue with shadow maps is that they substantially increase the usage of the GPU. For those using laptops or integrated GPUs, it could cause performance or heat issues. For those with decent dedicated GPUs, increased wattage (and therefore heat) can and does turn on its GPU fans. The wattage on my AMD RX 6700 XT can become tripled when using shadow maps. That's undesirable. The advice I give players is: There really isn't a "best" shadows implementation these days. Some devs and players prefer one over the other. Regardless of which is chosen, stencil shadows and maps are used where needed. So, I'd try out both and pick the one you prefer. Here's Fen complaining about shadow maps. Complaint #1 (7:28): Complaint #2 (23:46): In his next video (Written in Stone - 4 - Chocolate Coated Brendel Bar), he turned on stencil shadows, and as far as I know, he never complained again. The following area in Written in Stone shows a good example of alpha-tested shadow occluders. Yes, technically the moving leaves cast shadows, but it looks awful in game, in my opinion. I know others like it. The same scene using stencil shadows looks amazing in game. (The screenshots don't do a good job demonstrating how it looks in game.) The current hybrid system is fantastic. It gives people choice. Those who prefer stencil shadows can use them; those who prefer shadow maps can use them. People become attached to the "art" and "style" of a mission, and changing the shadow implementation changes the art and style. If one must be dropped, I'd say shadow maps should be dropped from the menu settings. Use shadow maps for volumetric lights and stencil shadows everywhere else. And, I agree with nbohr1more that defaulting to rules consistent with stencil shadows is a good idea.

That is already in the core game, for whatever reason the team decided to not include it in the GUI as an option, which is the only thing I did about it. You can enable it in the console with r_frobOutline 1 and r_frobOutlinePreset 6 anytime...

Hi! Basically, I made these changes purely for myself, but suddenly someone will be interested in playing with them in the same way. 1) Tweaked Lightgem Cleaner Design: I've streamlined the Lightgem by removing those small side details. After all, you already know if you're crouched, right? In-Game Look: Check out how it appears in your game: Editor View: Here's a peek from the editor for good measure: Easy Install: Drop the 'x_newlightgem.pk4' file into your game's root directory to install. To remove, simply delete the file. 2) Tweaked HUD Vibrant Upgrade: I've boosted the color intensity of your health and air bars for better visibility. Sharper Look: Redesigned the 'staples' along the edges, cleaned up textures, and added a touch more definition. Installation Note: Unfortunately, .pk4 files weren't playing nicely for this tweak. Simply unzip the included 'dds.rar' archive into your game's root directory. 3) Health\Air Bar Relocation Streamlined HUD: Health bar repositions for easier monitoring. Zero Fuss: No extra settings to mess with. Plays Nice: Works seamlessly with my other mods. How its look: Installation: Download the zzz_ui_settings.pk4 file. Place the file in the game's root directory. Uninstallation: Delete the zzz_ui_settings.pk4 file from the game's root directory. Let me know if you'd like any other tweaks! x_newlightgem.pk4 dds.rar zzz_ui_settings.pk4

Yes, but I used the user_addon_init script inside and this seems to also be in the core files so I got an redeclare error. I renamed that script and weird enough, on my home system it's working fine now :)! Maybe I made a typo earlier...

I figured this was only done to avoid missions breaking if they add their own stuff. Checking out the link above it doesn't seem to work with init scripts where most of the changes of the patch are. If I rename the tdm_user_addons file I get an redeclaring user_addon_init error and if I rename that, all the patch scripts are gone. So what am I doing wrong here?

I spend 90% of my time on Linux Mint. I occasionally pop over to Windows 10 to check a few things or run some updates but Linux Mint is my home. TDM runs better under Mint than Windows for me but your mileage may vary. When running TDM in Linux, you must set FPS to "Uncapped Mode" in the Advanced settings, the old capped mode has terrible stuttering and performance under Linux ( even native Doom 3 has this issue ). You can set Max FPS to 60 if you are worried about any inconsistencies with game timing ( the only known issues are rare problems with audio behavior at really high FPS). Just don't use the native 60FPS capped mode, use Uncapped mode with a Max FPS value.

Changelog of 2.13 development: dev17044-10746 * Supported mission overrides for cvars which are tied to gameplay state (5453). * Fixed crash on start with 32-bit Windows build. * Rebuilt all third-party libraries with conan 2 system (6253). * Reverted improvements of capped FPS to fix video/audio desync (5575). dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

We are proud to announce the release of: The Dark Mod 2.12 ! The 2.12 development cycle introduced many large code overhaul projects. Most of these were to lay the groundwork for future fixes and optimizations. The final release is yet another leap in performance over the already impressive 2.10 and 2.11 releases. A full changelog can be viewed here, but some highlights include: The Dark Mod 2.12 is a major step forward for mission designers! The culling system has been extensively overhauled to ensure that your CPU and GPU are not wasting resources rendering unseen geometry, lights, and shadows. Some of our best map optimization experts have achieved similar performance gains to what this new culling system does but it is a rare skill and we have even managed to improve performance on missions that were generally regarded as “well optimized”. Mission authors both new and old can follow standard mapping practices with no need to dive deep into sophisticated optimization techniques even for some pretty challenging scenarios such as wide open areas and long views. Players will immediately notice many missions that have made their system struggle with FPS now may be running much more smoothly! Smoother controls for players! Also during the 2.12 development cycle, work has been done to make controls more seamless and accessible. Frob can now use hold or click actions to use items. Once you get used to the mechanic, it will be hard to go back to using a separate “use key”. Mantling is now smoother, faster, and less prone to cause the player to clip through geometry. Leaning is now more subtle and less prone to cause motion sickness. To reduce the tedium of shuffling knocked out AI around to search for loot, you can now configure TDM to automatically loot any frobbed AI. A special thanks must go out to community member Geep! Over the course of 2.12 development, Geep has created subtitles for nearly all AI barks along with developing testing tools and procedures for this gargantuan task! You can see these changes in action by changing the Subtitles setting to “On” ( rather than “Story” ) on the Audio settings page. Geep also provided substantial feedback for our GUI and subtitle design process and edited font data to improve text quality overall. Datiswous has complimented the massive work by Geep to create AI bark subtitles by creating mission story subtitles for a large number of missions. Thank you! Turrets are now natively supported in The Dark Mod and can be paired with Security Cameras! Finally, the nasty 2.11 bug that caused AI to allow arrows to pass through them at certain angles was fixed by Joebarnin! Your assassin style play-throughs should be far less frustrating. See also, our 2.12 Feature discussions: To UPDATE, simply run the tdm_installer.exe file in your darkmod folder. Note that tdm_update.exe is no longer supported, but you can download the new installer from the Downloads page if you don’t have it yet. Please be aware that old saved games will not be compatible with 2.12, so finish any missions you might be in the middle of first! Also, some missions created prior to 2.12 may need to be updated so they will be playable in 2.12. Use the in-game mission downloader to check for updates.

Some parts are managed by tdm_installer, some parts are managed by in-game downloader. You mix the two, and you get endless stream of issues and confusion. As simple as that.

You'll be surprised to hear but I don't quite get it either. Based on my understanding, there are a few confounding factors that make this a challenge. 1. We did a lot of work to ensure that the "included missions" were made part of the install so first time players would have a curated experience. Moving the missions back to the mission database might require undoing that work. 2. It is entirely possible to add the missions to the mission database while also being included in the installer but doing this will invite a few problems: 2a. What if the user updates the mission and then finds that their TDM install is somehow borked. They might run the installer to repair it and this will revert the mission version. If they fail to update their mission after this revert they might have incompatible save games that cause crashes and confusion 2b. What if a user starts downloading a mission update and at the same time starts a TDM upgrade ? 2c. Users opening bug tickets for a base TDM version due to problems seen in the included mission that are no longer present in the updated one, thus making it more tedious to narrow down duplicate bug submissions. 2d. Players seeing the missions on the TDM missions download page and downloading the package to install in the FMS directory then seeing duplicates in the mission list because the downloads page renames the packages with hashed filenames. All the above challenges revolve around potential user error and even though it should be obvious not to do these things, we have to compare the above to the vast swaths of folks who are begging to include TDM into Steam because unpacking a zip file and running an installer executable within a folder is "too difficult and confusing". One thing that we have the ability to do is change the file in the 2.12 installer repo so that if users run the updater it will apply the new mission. This change would not be visible to users so they would not get any alert about it. We would just have to announce it and hope that players watch for TDM announcements. I am doubtful anyone would want to work on it but I suppose that there could be some way to pass some sort of signal to the mission downloader when included missions have been changed on the installer side so they get a different update indicator. Still would be kludgy because you'd either be telling the player to exit TDM and run the installer or making TDM invoke the installer internally. So that is my take on "why" based on my own knowledge. Of course, part of my inability to "understand it" is due to my incredulity that we need to cater to players who are so below the bar in computer literacy that they would inflict these problems on themselves in the first place. None of this is an official stance just my own take on why the proposal to "let two updater processes control the same files in the same folder" has been rejected ( other than that such designs usually horrify programmers on a primordial gut level and if you mention that any program that does this you will see any programmer in vicinity instinctively reach for headache or stomach medicine ).

Nomads of Driftland: The Forgotten Passage 100% off on GOG This is a DLC or expansion pack, but I was able to get the base game for free. https://www.gog.com/en/game/nomads_of_driftland https://www.gog.com/en/game/nomads_of_driftland_the_forgotten_passage

I enjoyed this one, particularly the straight forward game play, and sensible architecture. Thank you.

The Thief2 FM "Mission X" was structured like that. But from the perspective of someone making or using a multiplayer system, it should be as general as possible so mappers can make whatever set-up they want for their FM, like that, or leave it open to the players to play it however they want. I think one way for the system to work most basically is have a coop mode (shared objectives, loot, scripts, etc.) and a "thieves vs. guards" mode (separate objectives, tracking loot count & capture count; it should probably be set up like the old Thievery mod) and those are pre-made so a mapper can just turn one on and tweak some things. Those are the two most popular MP cases for this game. But then if they want to, mappers could micromanage the parameters if they want to make their own mode, and the system should facilitate that. That was my thinking. But I think coop is the big one for us, since all of the FMs will already be set up for that, and that's the way I imagine it'd be most used. So that should come first.

So I thought whether to mention this here, in the end I guess it makes sense as it's now technically a bug report. The discussion started out as a feature request, or rather a set of them... then it was mentioned that one of the functionalities I described should in fact exist, but an error is causing it to be overridden. We aren't sure when it was introduced but since I've always observed the broken behavior it might be years. You can read the full conversation here: https://bugs.thedarkmod.com/view.php?id=6436 What I observed and initially requested: When the player shoots at an AI, the AI shouldn't go searching in a completely random direction, and instead go somewhere toward the player as they should have a general sense of where the arrow came from. Currently guards completely ignore the direction of an attack and will cluelessly run to a completely random spot when hit which is very unrealistic: If an arrow hits you in the back, you aren't going to sprint forward looking for the perpetrator there. How this turned into a bug report: Someone investigated the issue and discovered that when attacked, AI should in fact be picking a search area between their own position and that of the players. I understand the pain event mistakenly overrides that decision, causing the guard to pick random locations within their own radius when attacked. Now that this is known, maybe this can be fixed in time for 2.12 so we aren't stuck with the broken behavior for the whole release?