Search the Community

I am playing on a humble i5 2500 with a Geforce 1050 Ti and TDM runs good enough for me :)!

I'm afraid I'm just about to get heavily tied up with some real life activities, so I can't help with any testing in the next few weeks. I'm not an FM author myself, but scripts seem to add complexity and the risk of malfunctions, both in TDM and Thief FMs. And I wonder if they are avoidable in these two instances. Are you sure the script is necessary at all with the lever, which is fairly hard to find? And might it not be simpler to move the jewel cases further from the window and dispense with the script?

Nope, TDM just keeps getting better so practically no missions challenge this old boy anymore. I'll probably replace it next year at the doomsday of Windows 10. Already pushing my luck with Spectre and Meltdown flaws in Ivy Bridge

Howdy! With recent discussions around shader design and rim \ fresnel, I decided to try adding this effect back to the 2.09 ambient. tdm_base01.pk4 (Bug fixed. You can now have bloom enabled! Recommended setting: r_postprocess_colorCurveBias to 0.35 Installation: Rename your tdm_base01.pk4 in your darkmod directory and copy this into that directory.

TDM Latch Pack (Beta) By Frost_Salamander and wellingtoncrab with special thanks to Dragofer Tired of picking another lock or hunting for that missing key? Imagine The City is itself an elaborate lock, and you are the key. Embrace progression through careful exploration and navigation of the environment. Embrace the latch pill: Included is a new entity type and scripting for a door mounted toggle lock, or "latch", as well as new CC0 assets and prefabs. https://github.com/thedarkmodcommunity/test-latch/wiki Example Video Asset Pictures All models and textures in this pack are released under CC0 license and may be used freely without need of attribution. We waive copyright to the extent that possible, but aren’t lawyers. Latch Lock Features Supports single and double doors across all cardinal directions, as well as trap doors Uses the location system to handle context sensitive frob highlighting of the latch and the doors Automatically determines the correct latch state on map start based on the targeted door's "locked" spawnarg Options for rotate, translate, or both with unique sound slots for each Supports any model or func_static To get started head over and grab the latest release (available with or without demo content) and read the getting started guide. This is a beta release - so your feedback is appreciated!

What a mission. All my favorite ingredients - verticality, story, secrets, optional objectives - in a setting previously unseen in TDM as far as I recall. Sneaking about felt incredibly fresh, almost like a different game. And the doors with the little latches! Unlocking shortcuts and passages was most enjoyable, which is good as it's a big mission with lots to explore. The Ministry was pretty challenging to stealth through with all the cameras, particularly the one on the top floor. Found 9 secrets out of 10 and a bit over 5k loot. The problem with the unfrobbable lever in the fireplace and the two display cases also happened to me. For some reason, when I started the mission again and noclipped over to the fireplace lever and the two display cases in the jewel shop, all of them could be frobbed. I guess I must have done something weird in the playthrough to change that.

If you mean I just retried both this and the cabinets in Jerry's on my test install of TDM and they both work fine. EDIT: I'm not saying there might not be an issue, but I can't reproduce them and if anyone can I'd be keen to hear the details.

I've been asked to post about the increased mantle speed in 2.12 as some folks have been curious about the change. After a lengthy internal discussion along with testing and input by several mission authors, it was agreed internally to increase the mantle speed. But during 2.12 beta testing, we would like feedback on any bugs or issues that you find. The reason for the change was to address feedback from players that mantling was "painfully slow", "slow and clunky", "mantling sucks - it's just slow", and so on. Several mission authors supported making mantling faster, and so the dev team decided to tweak the mantle speed. There were multiple implementations with the final implementation being a compromise. Also, the dev team studied some parkour techniques to ensure that the mantle phases and timings were good enough. The changes include: The original mantle phases were kept as that is what longtime TDM players are used to, and only the duration of some phases were reduced. Changed the pull animation so that it has both acceleration and deceleration rather than just deceleration. Tweaked the swaying back and forth a bit to work better with the increased speed. When the player in forced into the crouch position at the end of a mantle, crouch near the end of the mantle rather than the beginning in order to remove the sudden "dip" of the player's view. A majority of dev team members were against adding a menu setting, so being able to toggle between the old and new mantle speeds will not happen. It is recommended that you try out different "Mantle Roll" values as some prefer "0.1" and others prefer "0.5". We hope you all enjoy this adjusted mantle speed, especially the overhead mantle, which is now more consistent with the other mantle types. Bug tracker: https://bugs.thedarkmod.com/view.php?id=6343

So this online store I bought a pair of headphones from decided to gift me 12$ today. Since the voucher would expire in in two weeks unless used and I had nothing else to get, I decided to spend it on a 17$ gamepad so I'd have one of these as well. I understand they should work fine under Linux these days, plus it supports both dinput and xinput so I'm not concerned. I never played any FPS or most games using something other than the keyboard and mouse, this feels like an interesting opportunity to try it out. TDM is one of the games I might enjoy playing with such a thing, especially since it doesn't require super-fast reactions till I get used to it like a deathmatch shooter. So until the device arrives tomorrow, I figured I'd ask how well I can expect TDM to run on such a thing! Especially now that we have a new rendering and input management system for the upcoming TDM 2.10. There's a few things I wanted to know. One is if both looking around as well as movement using the finger pads is supported. I remember some games allowed walking more slowly if you only pushed the pad slightly; Does this mean it's possible to sneak by only moving the pad a bit, in a way that affects how much guards hear you? Otherwise I was curious if force feedback (vibration) is implemented and used. For TDM this mainly makes sense when you take damage, are in radius of a sound that has the shake effect, and other potential situations I might be missing now. Is gamepad vibration a feature in the engine at least?

Here is the latest version. I did major cleanup: fixed warnings, adjusted things for recent TDM, made indentation consistent. briefing_button.zip briefing_flowing.zip

Oops, I guess I should have read this poll/thread before posting comments about the relevance of 32-bit in the technical discussion about 32-bit Linux builds. My argument against catering to the people who have installed 32-bit OS on 64-bit machines is that this is a group of people who are: Tech-savvy enough to install their own operating system, but... Not tech-savvy enough to realise that they have installed the wrong architecture for their machine, and... Entirely uninterested in upgrading to a current OS version (which probably no longer offers a 32-bit option), or re-installing their OS to make proper use of their own hardware, and... Perfectly happy with applications being limited to 4 GB RAM, which is far too small for decent performance these days, but... Still expecting modern games to work. I assume this is a group of people who are vanishingly small in 2024, and if they do exist, their expectations are so unreasonable that we shouldn't care about them. If they really want to try TDM on their weird setup, they can always compile the source themselves.

One thing that makes or breaks the enjoyment for me has always been grounded movement. TDM had that human feel to it for as long as I remember playing it. I already had the privilege to pull myself up from ledges in complete silence, but with latest change I am also way too fast at doing it in complete silence. To me it does not feel satisfying at all, even after many many missions of trying to get used to it. Not trying to complain or make anyone feel like it was an unwelcome change. I'm probably just 1 person with a very niche issue. If there is a way to easily revert it by editing something, I'd love to know. To clarify, I'd like to achieve the type of climbing/mantling where your camera basically makes a small pause before pulling yourself more higher for second time. Along with generally slower obstacle movements. Thanks. EDIT: Posting solution here for other noobs like me: (Thanks datiswous, nbohr1more, Daft Mugi.) 1. create a Notepad file in "darkmod" folder called "autoexec", and save it as .cfg file. 2. insert the following lines and save the document: set pm_mantle_hang_msecs "750" set pm_mantle_pull_msecs "750" set pm_mantle_shift_hands_msecs "500" set pm_mantle_pullFast_msecs "450"

You get the option to "Restore old Config" after upgrade but we advise against it since sometimes it reverts new default settings for performance features that have been improved and tested enough to made default. I think the next TDM release will have FPS mode to uncapped as default since it is critical to Linux players but also fixes a few audio sync bugs and even improves things for Windows players apparently. On balance, uncapped mode is more fixed and maintained than the old id software capped mode. ( Quite a strange thing considering all the bugs we used to have with uncapped mode. )

This is NaN value being spread by bloom. Usually it happens AMD GPUs, since NVIDIA apparently drops NaNs from framebuffer today. I hope this is some old TDM version

Hey I just wanted to create a Thread where everybody can post his improvement wishes. I Personally love this mod. There are so many features in it, and because it is a mod created by a community, why not write what could be improved. My wishes are: Some special weapons. I loved T2X and the variety of weapons. Some really hard to find special weapons, like the confusion arrow or a special bomb would be cool. But they have to be very special, for example as a result of a side quest - or maybe a usable torch for easier killing the undead More enemies, I think there will be an improvement, we just got spiders and zombies, but a higher variety is always good. More (custom) conversation. Thats one of the main parts I'm missing - so much flair and atmosphere is getting lost without them. Also some comments from he main charakter would be nice. For example when a guard gets knocked out "hah, now who's the taffer" ... better AI when the hear a voice. They start looking for you, but most of the time I just sneak into another room or a higher area and just have to wait, they should at least get someone with a torch or call other guards for help These are only small parts of the game which could be improved and are only my points of view, maybe it's either not possible to create or it fits not in the design of TDM.

If the question is whether or not you want to maintain the 32-bit version of TDM, I'd say that it's probably such a rare use case that it doesn't make sense.

It would be nice to be able to create your own EFX presets, this will solve that issue. https://github.com/kcat/openal-soft/blob/master/include/AL/efx-presets.h lists all the presets. Here they can be seen in the tdm source file. I think these could be read from an external file instead of inside game code? If TDM reads the presets from an external file, anyone could easilly make their own presets by overriding that file and these could be used inside a spawnarg when that gets implemented.

It's that time of the year again (and again and again, Nietzsche - and Far Cry 3's Vaas - was indeed right ) http://www.moddb.com/groups/2017-mod-of-the-year-awards/ Vote for TDM, you taffers! (-> http://www.moddb.com/mods/the-dark-mod )

You're on TDM 2.12 correct? Please post your current Darkmod.cfg Also, the performance wiki has been updated recently: https://wiki.thedarkmod.com/index.php?title=Performance_Tweaks

Cheers! I've been wondering for some time now if it would be possible to compile the source code of TDM to the Raspberry Pi, especially the models 3 and 4. I've seen some videos online of people running Doom3 on it, so how hard would it be to compile the source of TDM for the raspberry pi? Would it need a major rewrite of some parts of the code? I've been "tinkering" with the source for some days, and as I was expecting, all the configuration files are made for x86 architectures (Linux and Windows). I've been searching online for some info about the toolchains needed to even start compiling the source for these arm machines, but the information has been quite lackluster and outdated. I've managed to track down a toolchain to compile c++ code for the raspberry pi, made by the pi foundation but I'm not quite sure how to use it and I guess the support for it has been dropped for quite some time now. Anyway, I figured that instead of wasting more of my time, it would be best to ask here what you guys think. Is it possible to even think about this, or does TDM use some kind of libraries or other external code which makes it impossible to compile for the pi? Is there anything related to the game that makes almost impossible or too much of a hassle to try to port the game for the raspberry pi? Performance isn't an issue for me. I just want to know if it can be run in that machine. If it is possible to do this without a major code rewrite of the game, where should I start? I have no experience on compiling anything for arm, only some experience in x86, so this might be a fool's errand, but I would like to give it a try nonetheless. If it is possible to do this and if some of you could help me in any way, that would be appreciated. On the other hand, if you think this is a really hard thing to even try to do, please feel free to tell me so I don't waste more of my time. Thanks in advance

So I was reading the DarkRadiant Script Reference and it gives an example to move the cameraview by setting coordinates: import darkradiant as dr camview = GlobalCameraManager.getActiveView() camview.setCameraOrigin(dr.Vector3(50,0,50)) This works, but then I wanted to use the tdm position coordinates that you can get by doing getviewpos in the console in tdm. But these coordinates don´t give the same position in DR. Why is that? Is there an other way? Edit: WHOOPS it does actually work. (some layers in the testmap were disabled)

My new mission, A Night in Altham, is available. We are already up to version 2! @Dave the Tafferfound an problem that deserves a fix, so here is version 2: https://www.dropbox.com/scl/fi/y4r1dmziuq6clh2im3qz1/altham2.pk4?rlkey=m3cv5v6v70lxbc9xha61nuxoj&dl=1. I will ask @nbohr1more to update the databases. Thanks to JackFarmer (alpha testing and custom ambient music) and the many beta testers (jaxa, Shadow, wesp5, Cambridge Spy, thebigh, datiswous, Mezla, MirceaKitsune, Melchior, Acolytesix, TheUnbeholden, prjames, Bergante). Thanks to @peter_spy for his beautiful Builder Compound assets. This is a large mission, so be ready to take some time. I recommend that you do named saves occasionally (I actually implemented auto-saves for this mission, but it was causing crashes on Linux, so I removed it). This mission has a lot of keys, so it implements a key management mechanism. Keys are removed from the game when no longer needed. This includes when you use a key to open a door, or if you pick a door/lock that also uses a key. Most keys are automatically removed, but there are a couple that aren't (for example, if they open up more than one door). In a certain area, this mission uses the Keyhole Peek feature of TDM. Typically, this is when you lean forward (F key) into a door keyhole and you can see into the next room. But in this case you don't lean into a keyhole. It's a hole of another kind. It's an unconventional use of something that isn't used a lot in TDM; hopefully the mission context will make it clear when to use it. The mission does not use Keyhole Peek for regular doors. Be aware, there is a known problem on Linux, where the peek feature can cause a crash. Peeking is not required for mission completion. This has been tested on TDM 2.11a and the current dev build of 2.12 (dev16854-10518). Scary things warning: Difficulty settings make a difference. Things that are affected by the difficulty level: Enjoy!

For free ambience tracks it's as Freky said: you look around on the internet for tracks with the appropriate license to be included in your FM. Fortunately, you likely don't even need to bother doing this as a beginner as there's an entire "Music & SFX" section of the forums full of good ambient tracks for you to use if the stock tracks do not meet your fancy. You might also be interested in Orbweaver's "Dark Ambients", which come with a sndshd file already written for you.