Search the Community

It seems like more and more "thief" and "thief players" is becoming a short hand to dismiss community members earnest desire to improve the game - which happens to be a barely legally distinct "thief style" game which was made by thief fans for thief fans and is "designed to simulate the stealth gameplay of Thief". Who is the predominant player base of the game supposed to be beyond fans of the thief games? Is there some better avenue to find feedback for the game beyond this forum? FOSS and linux forums? I have seen maybe half a dozen posts from that segment. I am a thief fan, I play thief fms, my association with those games is what drives me to play and make things for this game. Are we supposed to pretend the original games are not a huge reason why most of us are here at all? TL;DR version:

That honestly sounds a description of the current patch to me - you never responded to my question as to why you view it as “radical”, why you feel like there is justification for you to redefine the scope of the patch at this point to not address the concerns of these players, and way there is cause to not consider expanding the test base by including the patch in an actual dev build? You mention the code has been this way for a long time - it takes a very shallow glance to see how long players have also been posting on this forum asking how to shoulder a body and getting some frigid responses about reading the wiki or playing the training mission. It has been consistent since at least 2009. The idea that a game that is still in active development can’t strive to improve these things just does not resonate with me at all.

Thanks! 1) Doing LONG_PRESS PAD_A (what I, for lack of knowledge, call "jump-mantle" or "_jumpmantle") differs from doing PRESS PAD_A ("_jump"). "_jumpmantle" differs from "_mantle", so they must be mapped to different button-calls. "_jumpmantle" differs from "_jump", so they must also be mapped to different button-calls. This appears to be the case, but it is not evident (or changeable) in DarkmodPadbinds.cfg. "_jumpmantle" seems to be hard coded to always connect to the same button as "_jump" but with a long press. It is as if bindPadButton PRESS PAD_A "_jump" is not actually just binding PRESS PAD_A to "_jump", but rather interpreted as "link PAD_A (regardless of button press time) to behave exactly like keyboard SPACE for short and long presses". I would have expected the default DarkmodPadbinds.cfg to explicitly read: bindPadButton PRESS PAD_A "_jump" bindPadButton LONG_PRESS PAD_A "_jumpmantle" bindPadButton PRESS PAD_B "_crouch" bindPadButton LONG_PRESS PAD_B "_mantle" ... but neither LONG_PRESS PAD_A or "_jumpmantle" is listed in the file. If there are actions "_jump" and "_mantle", I suppose there must also be an action "_jumpmantle" since it is possible for the player to do all those movements: * "_mantle" does the movements "crouch on the high surface, then stand up" * "_jumpmantle" idoes the movements "jump slightly forward, then land standing on the high surface" * "_jump" idoes the movements "jump up, then land exactly where you started" If the actions "_jump" and "_moveup" are not synonymous, then perhaps the action "_moveup" is what i call "_jumpmantle"? 2) Thanks for the link! It was useful in more than one way. I'll link to that page from https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings#Gamepad_Default_Bindings if I can get an account on the wiki, which proved more difficult than i thought (https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/). However, it does not answer my question how to find out the name ("<button>") used for a button on my gamepad. Basically, I would need to press the button on my gamepad and some program could tell me "That button is called 'PAD_A'". In my case, I have a gamepad "Logitech F310" (https://commons.wikimedia.org/wiki/File:Logitech_F310_Gamepad.jpg) which has a "Logitech button" (see image) that I want to use. I was hoping to find out the "button name" for that button and then edit DarkmodPadbinds.cfg to map it to a function. 3) ... but if that button has an "unusual name" that TDM does not recognize, then it may perhaps not work. E.g. if that button is called "PAD_LOGITECH" and TDM cannot recognize that name, then I cannot map anything to it via DarkmodPadbinds.cfg. Using QJoyPad I can map any keyboard key to it instead, as a workaround, but I cannot map MODIFIER to it (since MODIFIER cannot be set to a keyboard key). If current implementation is still called "experimental", then I must say it works very well; @cabalistic: kudos for that! I may not have continued playing TDM had it not worked with a gamepad.

Hi folks, I'm finally coming back to this after some time I've found that the latest SVN revision (10623 at the time of writing) is broken on FreeBSD 13.2/clang 14.0.5 again, but am preparing patches to fix them. Some of these issues include: Printing strings in `game/LodComponent.cpp` missing `.c_str()` INFINITY is a system-wide macro in <cmath> that conflicts with idMath::INFINITY Is renaming it to ID_INFINITY the right move here? ALIGN is a system-wide macro that conflicts with ALIGN in `idlib/sys/sys_defines.h` I plan to rename the macro to something like ID_ALIGN to avoid the conflict The `register` keyword is not allowed in C++17 While I prepare patches for these issues, what's the best way of providing patches upstream? As a patch upload here, or something else? I've also noticed that there is now a Git mirror (thank you), which makes it easier for me to prepare local commits and separate different patches from one another for purposes of upstreaming.

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

It is possible that this is a setting that needs to be activated to work: https://mantisbt.org/forums/viewtopic.php?t=23221

I tested the new Hazard Pay version with my patch and I still get errors when starting it, because the mission contains the same statistics scroll script as my patch and doesn't like that variables and other things are reassigned. Is there an easy way to avoid missions breaking if they include duplicate scripts or do I need to rename everything in my version and hope that nobody uses the same names? I can imagine the same happening to snatchers mod, like if a mission editor likes a feature and includes it in his mission, the mission will break once snatcher's mod is installed in case names are the same...

Here's the draft code patch so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! https://gist.github.com/daftmugi/43a23ca3471ae1d49eb0b9aa92ea8457 Install TDM v2.12 (dev16818-10434) Get the SVN repo Download "r10452-add-lean2.diff " Apply SVN patch: "svn patch r10452-add-lean2.diff" Compile Copy TheDarkMod.exe and glprogs to TDM (dev16818-10434) directory Or, @Wellingtoncrab has provided a Windows build. (includes new frob and new lean) Install TDM v2.12 (dev16818-10434). Download @Wellingtoncrab Windows build: https://cdn.discordapp.com/attachments/1062478154310103120/1154930878162669750/TheDarkModx64.exe Copy the TheDarkModx64.exe binary to your dev16818-10434 directory. Or, @Daft Mugi has provided a Ubuntu/Linux build. (includes new frob and new lean) Install TDM v2.12 (dev16818-10434). Download @Daft Mugi Ubuntu/Linux build: https://drive.google.com/file/d/1kUZtQrkAQpPHVRUX_JrhxSeWkzZX8P4D/view?usp=sharing Copy the thedarkmod.x64 binary to your dev16818-10434 directory.

I am going to sort-of reveal that this is loosely like the nature of my upcoming mission. I noted it here when JackFarmer asked about things that are coming along in this post: https://forums.thedarkmod.com/index.php?/profile/37993-jackfarmer/&status=3943&type=status It too is a builder church. The player is requested by a hopefully famous character in another mission to handle some business that is affecting the congregation. I am looking to invoke some info and history laid down in other missions as a hook story.

I admit that I was skeptical myself at first, but once I tried it in game, I changed my mind. So, I recommend applying the patch to a local build and give it a go in game. It's definitely better experienced than thought about. Regarding the candle puzzle in "Seeking Lady Leicester" (SLL), I agree that this proposed change will make that a bit more difficult, but I disagree on the reason why. The released version of SLL has a flint in the inventory to ignite them, so accidentally extinguishing candles shouldn't be much of a problem. Instead, I think the reason for player frustration would be that the unlit candles highlight, showing they can be frobbed, but when the player does frob, nothing would happen. They might not realize the candles can be picked up with a long-press frob. @Wellingtoncrab and I had a discussion about that exact puzzle during the design of this feature. So, what convinced me that it wasn't really a problem? I tried it in game. Players will learn how unlit candles look and behave when frobbed. Like @ChronA said above: "When most players click a candle 99.8% of the time they don't want to move it, they want to put it out." I decided it was better to optimize for what players expect most often and do most often rather than optimize for rare cases. Players already rage in frustration that they have trouble extinguishing candles or don't realize that they can. Another quote from a player on Discord: "I'd even say the "some players didn't know you could extinguish candles by using them" thing is "almost any new player and a lot of old ones too", since I once had an extended conversation about exactly how immersion breaking and weird it was to have to extinguish candles by dropping them, and literally not a single person brought up the fact that [extinguish candles by using them] was possible." During beta testing, the struggle that some beta testers had with the candle puzzle was not knowing about object manipulation. They didn't know about the "Parry/Manipulate" keybinding, or they forgot about object manipulation because they did the training mission roughly 5 years ago and had not needed to do it in a mission afterwards. So, "long-press frob to pick up" is in the same class of player interaction as object manipulation. In other words, the same problem already exists in TDM v2.11. I couldn't find the original screenshot from one of the SLL beta testers, but here's one similar, showing that the player didn't know about object manipulation: If this is truly in a released mission, I'd like to know about it. We can problem solve for that case if it does in fact exist. I don't think we should concern ourselves with something hypothetical, though. And, I disagree that we should make or keep controls cumbersome for the player in order to add challenge. I agree with @ChronA here. I don't think players are playing TDM for that type of challenge. The patch includes the following cvar: "tdm_frobhold_delay", default:"300" The frob hold delay (in ms) before drag or pick up. Set to 0 for TDM v2.11 (and prior) behavior. When "tdm_frobhold_delay" is set to 0, candles and bodies have the same behavior as TDM v2.11. As of a few moments ago, bodies didn't quite have the same behavior. But based on your feedback, I updated the patch (linked above) to make bodies behave that way. Thank you for your feedback.

I created the page: https://wiki.thedarkmod.com/index.php?title=Lightgem In the source I placed the following text: <!-- Page text made by forum user Fiver: https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/&do=findComment&comment=491145 --> Personally I think the page isn't really necessary because the info is already present under HUD.

I haven't personally run it so not sure how long it actually takes. @Amadeus how long did it take for WIS? @stgatilov To make runParticle part of dmap, is there a way to check if runParticle needs to be run or not first? For example, if there are no particles present with 'collisionStatic' keyword than just skip it. I wouldn't say this is big deal, but it's a manual step that the mapper could easily forget to run on release day... I meant the default weather materials - but Amadeus covered that in his question - thanks. Actually this doesn't seem to be the case. The rain seems to stay outside the visleaf if the door is open. In the example screenshot from inside the Inn in In Plain Sight, the rain patch actually extends over the roof of this building. With the door open, the rain 'stays outside'. However, you're right and still with this method you need to use individual patches and place them carefully (although I didn't have to worry about the height). It's not perfect because rain will still poke through awnings and stuff outside.

So, I do have some experience using the particle collisions for Written in Stone. At the time of development, I had to make custom weather particle and material defs in order to get it to work properly. Honestly, while the system is nice when it does work, it is complicated, quite a lot of work on part of the mapper, and can be very finicky. A minor change to the map can break the system (to which, the runParticle command needs to be run again after mapping). One thing I don't get is why TDM doesn't have core materials that support particle collision right out of the box. There is a small handful of rain materials that support this, but most of the core weather textures, and particularly snow textures, all use "deform particle2" even though that is not supported by particle collision; "deform particle" is the correct keyword for this (as per the article here. I can't imagine why a mapper would ever want rain and snow to pierce through brushwork, like a ceiling in a house. And even if the mapper did want that, they could simply place a weather patch on the ceiling to make that happen.

In W10 it works flaeles without patch. Its somewhat strange, it was a game only for WinXP and never works well in W7, even with a patch. But in W10 I never had problems. And now you say it needs again a Patch in W11? Very strange. Anyway, yes, it's a real Gem which I like a lot. Amazing image quality and playability for so few resources it need.

Here's the draft code patch so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! https://gist.github.com/daftmugi/41d0324107e8734f364bb3e50ff00794 Install TDM v2.12 (dev16829-10455) Get the SVN repo Download "r10455-add-frobhold.diff" Apply SVN patch: "svn patch r10455-add-frobhold.diff" Compile Copy TheDarkMod.exe and glprogs to TDM (dev16829-10455) directory Or, @Wellingtoncrab has provided a Windows build. (includes new frob and new lean) Install TDM v2.12 (dev16829-10455). Download @Wellingtoncrab Windows build: https://drive.google.com/file/d/13lQig7Yzfc_jovU2zZklxLV1QOKAjkXe/view?usp=sharing Copy the TheDarkModx64.exe binary to your dev16829-10455 directory. Or, @Daft Mugi has provided a Ubuntu/Linux build. (includes new frob and new lean) Install TDM v2.12 (dev16829-10455). Download @Daft Mugi Ubuntu/Linux build: https://drive.google.com/file/d/1j7DoWBKuBAFdVH2Y-2LcYsgdtJNBabmn/view?usp=sharing Copy the thedarkmod.x64 binary to your dev16829-10455 directory.

In the first post of the other topic Geep proposed: Then Stgatilov's answer: But I think applying subtitles in different languages shouldn't be too hard I would think, but I don't know how the current translation system works. The engine should apply the correct subtitles based on the applied language setting, this doesn't need a whole new language system I think. Not sure who's going to write those subtitles though. I can only do Dutch and English and nobody needs Dutch I think. I suggest further discussion of this to take place in topic https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/

I dom't use it, i found it here with the filter set to OpenSource. the TOS and PP isn't excluding for an OpenSource app, if they use ads mean that they also need to pay an server for this online service. OpenSource is not synonymous with free either, perhaps after the beta phase it is no longer free, so perhaps you can take advantage of the fact that it is still free to create a series of textures that can be used or search another one in Futuretools. AI generated textures and assets, by definition, don't have any copyright, so you can use them as you want. https://www.futuretools.io/?pricing-model=free|open-source&tags-n5zn=gaming

Extensive customization options are appropriate during the pre-release testing or early roll out of a new feature. The people testing the feature can't know yet what configuration will work best for them, much less the people making the patch. My expectation is that by the time you have to make a final decision about including this patch in the next official update of TDM, there will be a rough consensus about the optimal parameters for the new mechanics, and you will only need one toggle for the new behavior. Or, preferably, there would be no need for an option at all if we can only get over our OCD about preserving arbitrary semantic grouping in our key-bind allocations; and embrace a superior control scheme that's not designed around highlighting an old gimmick feature whose trendiness expired with the Half-Life 2 era of FPS. But that's a pipe dream. Maybe instead we can just all agree that the general>gameplay options are getting a bit crowded. Perhaps we could split some of them off into an "appearance" or "accessibility" tag. As more people make their own mods and we modernize our accessibility options it is going to become a problem regardless. Best to get ahead of it. I agree, and that is one of TDM's strengths. It borrows and combines many of the best features from the three beloved Thief games, but it also gives FM creators tools to expand their creative vision in new directions. To some Thief purists that will never be an enticing proposition. But I don't see this feature as throwing a bone to those Thief players specifically, but just player in general who are bouncing off our game because it deviates from some genre conventions for no obvious reason, which makes them think this is an unpolished product. It is true that Thief was what set these conventions, and (shockingly/s) it is mostly Thief players who are interested enough in TDM to give it a try... but our responsibility to address these problems (if we can) is the same as if AMD or Linux players were having technical problems with TDM. They are people who we want to be part of our community because we never know if one of them might make the next FM like Iris, or do something crazy-innovative with TDM that we can't even imagine!

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751 I suppose the main questions are: when should this spawnarg be used, if at all? why was it introduced in the first place? Can we get it documented properly on the Wiki so misuse isn't propagated? @stgatilov @Dragofer

Mandrasola is a small sized map in which aspiring thief Thomas Porter steals some herbal products from a smuggler. The mission was created by me, Sotha and I wish to thank Bikerdude, BrokenArts and Ocn for playtesting and voice acting. Thanks goes naturally to everyone contributing and making TDM possible. This mission occurs chronologically before the Knighton's Manor, making it the first mission in the Thomas Porter series. Events in chronological order are: Mandrasola, The Knighton's Manor, The Beleaguered Fence, The Glenham Tower and The Transaction. The winter came early and suddenly this year. Weeks of strong blizzards and extremely harsh cold weather hit Bridgeport hard. With the seas completely frozen, a rare occurence indeed, most of the City harbor commerce has stopped completely. Vessels are stuck in the ice and no ship can leave or enter the City, resulting in the availability imported goods declining and their prices skyrocketing. One of these imported items is Mandrasola, a rare herbal product, which is imported overseas from the far southern continents. Mandrasola has its uses in alchemical cures and poisons, but mostly this substance is used for its narcotic qualities by commoners and even the nobility. The problem with Mandrasola is that excessive use is extremely addicting and the withdrawal effects are most grievious. Many are utterly incapable of stopping using Mandrasola and are transformed into quivering human ruins if they do no get their daily dose. And now this expensive and rare substance is running out from the whole City. Me and my fence, Lark Butternose, would love to grab this monopoly to ourselves: selling the last few doses in the City would probably be worth a fortune. According to Lark's sources, there remains only one smuggling lord who still has Mandrasola in stock. The problem is that this individual maintains an exclusive clandestine operation and only supplies a few nobles. Despite our best information gathering efforts we couldn't learn who the smuggler is and where he or she operates. Luckily we have an alternate plan. While searching for Mandrasola related information, we learned that a noblewoman called Lady Ludmilla is addicted to the substance and has paid high prices for small amounts of it. We also know that she has visited frequently someone in the Tanner's Ward waterfront, and since she goes to the area personally we believe she is visiting the smuggler. The plan is simple: I must monitor Ludmilla's most likely entryway to the Waterfront and then follow her to the smugglers hideout. I'd better be very careful around Ludmilla. She must not realise I'm following her or she probably won't lead me to her dealer. Hurting her is also out of the question. After she leads me to the smuggler's hideout, I can take my time to break in carefully and steal all the Mandrasola I can find. While I'm there it wouldn't be a bad idea to grab some loose valuables as well. I've now waited in the blistering cold for a few hours already. Looks like there are a few city watch patrols in the area to complicate matters... I think I heard a womans voice beyond the north gate. That must be lady Ludmilla, I haven't seen many ladies in these parts. I'd better get ready.. Links: Use the ingame downloader to get it. WARNING! Someone always fails to use spoiler tags. I do not recommend reading any further until you've played the mission.

I can confirm that the water is pitch black in "Noble Affairs". Also I suggest to remove "guard" from the tip on auto-search, because other NPCs carry items too, better make it like this: "Take all items from a body on first frob." Overall a nice release with several features that I can now remove from my patch, like directly extinguishing lights and mantling with bodies .

Hello! Tracking down information on software and plug-ins that work with D3 / TDM can be a tough. So I have created a thread here where people can post what software/ plug-ins/ tutorials or other references they've had success or failure with in TDM. 3DS MAX 2013 64bit .ase - Default .ASE model exporter works. However you have to open the .ase file in text edit and manual change the *BITMAP line on each material to read something like: "//base/textures/common/collision" which allows the engine to read the correct material path. md5.mesh / animation - Beserker's md5 exporter/importers for 3dsmax. http://www.katsbits.com/tools, Importing and exporting works. The model must be textured, UV'd, with a skin modifier attached to the bones to export. PM me (Kingsal) for help with this. Imported models using the script will not be weighted appropriately, so this is not recommended if you are simply trying to edit existing tdm content. (Use blender instead) MAYA 2011 32bit md5.mesh - So far I've not had any luck with Maya 2011. I am using Greebo's MayaImportx86 for Maya 2011. I've got the importer working however I get a "Unexpected Internal Failure(kFailure)" and the import fails. This could be due to something finicky in Maya that I am not doing correctly. Will keep trying.. Blender 2.7 about - Blender is commonly used and pretty well supported on the forums/ wiki. Various versions may work as well - https://www.blender.org/download/ md5.mesh / animation Blender MD5 importer/exporter (io_scene_md5.zip): https://sourceforge.net/projects/blenderbitsbobs/files/ Sotha's guide Blender Male/ Female rigs by Arcturus - Here Edit by Dragofer: more links found in this post.