Search the Community

There is a new system in 2.14 for generating smoke particles (6309). In general, it reuses more common code from the other ways to generate particles (particle models and particle deform) and its behavior is more aligned with those other ways. Here are some of the differences compared to the old system that I know of. 1) The new system is FPS-independent. If I'm not mistaken, the old one I think generates 5x particles on 300 FPS and 25% of the particles on 15 FPS. 2) Two systems have a bit different spawning time. Particle stages normally work on periods of length (particleLife + deadTime). In the old system, particles spawn uniformly during the first (bunching * (particleLife + deadTime)) time, while in the new system they spawn during the first (bunching * particleLife) time, same as in particle models and particle deforms. 3) The old system does not respect cycling settings in the particle decl. It plays only one period of every particle stage and stops. However, func_smoke specifically has a high-level logic: it restarts itself if all the particles have been generated. This looks like infinite looping, but all the particle stages have the same period in this case (the maximum one). The new system can respect "cycles" parameter from .prt file if you set spawnarg "use_cycles" = "1" on func_smoke entity. So if your .prt file has e.g. 3 stages with different period and "cycles" = "0", then each stages will cycle infinitely with its own period. And if your .prt has "cycles" "10", then func_smoke will play 10 periods and stop. Note that without "use_cycles" spawnarg both systems just play one period of all particle stages. This is a very recent change. The new system is enabled by default, but it is controlled by cvar g_newSmokeParticles. If we discover serious problems with it during beta, we'll have to flip the cvar...

Yuletide Boon The idea behind this mission was to again show, what can be built in a small amount of time and with help from other community members. It also showcases the new church modules that I don't think have been used all that much in previous FMs. Enjoy Notes: - TDM 2.13 or later is REQUIRED to play this mission. - Build time roughly 50hrs. - I have created serveral new custom models and prefabs for mappers to use, based of the church models. Download Link: - (v1.2) - https://mega.nz/file/qV1UQKqK#B9cdy3iB_Z7q8j2nQOEc9KISw8cPSYLIowP-1yokRbI Credits: Special thanks: - Springheel for creating the church modules. - Jack 'mozart' farmer for the briefing video and menu music. - datiswous - subtitles. - Goldwell - voice acting and briefing additions. - Dragofer - pagan statue from http://www.cadnav.com/3d-models/model-40413.html - Misc - Melted candlewax texture from - www.pexels.com/photo/close-up-of-wax-of-a-melted-candle-17959695 - Amadeus - scripting beta testers: -Jackfarmer, datiswous, CambridgeSpy, DavyJones, Mat99, Amadeus.

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

The Doom 3 engine has some architectural limitations: everything which can be rendered and lit must be a "render entity", and they are usually tied to game entities. For that reason, projected decals (i.e. the ones generated dynamically using the world geometry) are rendered with some lightweight processing, which excludes any possibility to interact with lights. The architecture of projected decals has been changed in TDM 2.14, and now they can interact with lights just like any simple func_static, for instance. What's the point in this change exactly? Well, it was requested by @Dragofer a few years ago, when he tried to add some depth to guards' footsteps on the snow by applying normal maps. Normal map is only used in lighting equations, thus it had no effect at all on the projected decals previously. From now on, if decal's material has interactions stages, it will be lit. So normal map and specular map finally make sense for projected decals just like it makes sense for static ones. The new behavior is enabled by default, but is a potentially breaking change. If we discover that some missions have become visually ugly because previously inactive interaction stages have become active, we'll try to fix missions. If there are too many issues, we'll have to restore legacy behavior by default and hide the new behavior behind material parameter. Right now it is possible to switch between two systems using cvar r_decalInteractive. Here is the testmap originally made by @Dragofer, with normal-mapped footsteps generated as projected decals: You might have noticed that footsteps are too bright where they overlap. That's because light interactions are additive in our engine, so each of the overlapping footsteps makes the image brighter. The usual way to avoid this is to make surfaces opaque, but then we'll get all the joy of depth fighting which is very hard to avoid in such a dynamic scenario. So yeah, while technically decal interactions are possible, unfortunately it does not necessarily mean that it works well in every imaginable scenario. P.S. The tracker issue is tracked as 5867.

If I try to rotate a model, only the Rotation option is available in the transformation window. No option to scale: Is this normal? Also not able to do so in NetRadiant-custom. Found a solution: https://wiki.thedarkmod.com/index.php?title=Model_Scaling Mods, please delete. Sorry about being dumb.

The engine has a rather cool feature of rendering perfect planar reflections using mirrorRenderMap. But it is well known that this feature can be costly, because it requires the whole world (in the worst case) to be rendered twice. There has been a request to support lower-resolution rendering to reduce GPU load (5485). This feature is added in 2.14 with new keyword mirrorResolutionFactor. For example, in order to make mirrored rendering with 1/3 x 1/3 of native resolution, you can write the following in your material: mirrorRenderMap mirrorResolutionFactor 0.333 Of course, this has a downside of making the mirrored view more blurred. But I've seen materials which explicitly blur the rendered view, distort it, or blend with other effects, etc. In these cases the lack of crispness of the reflections is not that ugly. The second change is related to the similar feature remoteRenderMap. There has been a way to specify resolution for this feature already, but it has some weird behavior and thus is now deprecated. If you have a square screen and want it to be rendered at 512 x 512 pixels, then you can write: remoteRenderMap remoteResolution 512 512 A slightly more convoluted way is to specify three numbers: remoteRenderMap remoteResolution 1024 1024 10.0 It means: render 10.0 pixels per 1 doom unit, but limit resolution by 1024 x 1024. So if the screen is of size 64 x 64 doom units, then it will be rendered at resolution 640 x 640, if it has size 16 x 16 units, then it will be rendered at resolution 160 x 160, but if it is stretched over 200 x 200 screen, then it will be rendered at resolution 1024 x 1024 because of the cap. There is also another limit for the remote screen resolution, which is applied at the end: see below. Finally, TDM 2.14 includes a few generic optimizations for these two features: Remote screen resolution is now capped by its size on the screen. So if a remote normally has 512 x 512 resolution but the player looks at it from far enough and it occupies only 100 x 100 pixels on the screen, then the rendering resolution is lowered to 128 x 128. This is controlled by cvar r_remoteLimitResolutionByScreenSize. Mirrored view image was previously copied at fullscreen resolution. Now the copy is limited to bounding rectangle/scissor, which means wasting less GPU bandwidth for mirrored surfaces which cover a small portion of the screen. Remember however, that all the resolution/scissor tweaks can only reduce GPU load. They don't simplify the work of the renderer frontend. So if the game is CPU-limited, none of this helps.

Glad I came to the forums to check out more details about this mission after playing. I was a little confused by a Bikerdude FM only taking 10mins to run through haha. Knowing it's a tech/build demo means I'm not going to spend the next hour or so looping through it trying to figure out if I missed a secret Krampus area or encounter xD.

Since TDM 2.14, there are global macros/defines which reflect the version of the TDM engine. The defines should be available everywhere in game scripts and in GUI scripts. Their values are like this: #define TDM_VERSION 214 #define TDM_REVISION 10969 #define TDM_VERSION_FULL (TDM_VERSION * 1000000 + TDM_REVISION) All of these versions grow monotonically. TDM_REVISION is the SVN revision of the source code repository. Of course, the final 2.14 release will have different value of TDM_REVISION. You can use TDM_VERSION to distinguish between major public releases, and in principle you can use TDM_VERSION_FULL to distinguish dev builds and betas. These macros add more flexibility in making missions compatible with different versions of TDM. I don't think mappers need to use them. It is more useful to the mission maintainers who can now absorb small breaking changes more easily. Here is the specific example it was implemented for: X-ray glasses breaking change. TDM 2.14 no longer applies tonemapping / gamma / brightness to UI elements. Achieving that required more refactoring in X-ray GUI. As the result, it became necessary to handle X-ray overlay in a special way in the engine. But the old way of creating X-ray overlay was not special at all, the engine could not understand which overlays were created for X-ray! So I had to add a new script event createXrayOverlay. Thanks to the version defines, it is possible to fix missions in such a way that they continue working both in 2.13 and in 2.14: #if TDM_VERSION_FULL >= 214010967 overlayHandle = $player1.createXrayOverlay(getKey("gui")); #else overlayHandle = $player1.createOverlay(getKey("gui"), ZOOM_GUI_LAYER); #endif Since TDM 2.13 and earlier do not have these macros, the C preprocessor assumes they to be zero there. The condition evaluates to false, and preprocessor removes the first line and leaves only the second one. In TDM 2.14, the condition will evaluate to true, so the preprocessor will leave the first line intact but delete the second line. P.S. This exact approach is used for compatibility in C/C++ programming with builtin macros like _MSC_VER and __GNUC__.

"It also showcases the new church modules that I don't think have been used all that much in previous FMs." 'new' church modules? We've had some for ages but were some new ones added recently? Which release were they added in? Nice little mission, it looks great and now I have a good reference for a cave if I ever want to build one . My only gripe is

Back in the day, Tels managed a squad of volunteer translators for TDM. I am not Tels, and could never do that. Nowadays, language translation using AI, either traditional machine learning (ML) models or large language models (LLMs), is common and increasingly fluent. It is often used as an adjunct to speed the work of professional human translators. By itself, AI translation can be imperfect but usually sufficient. Can this "sufficient" approach be used for TDM, to expedite translations? Let's see. I gave some initial thought to a bulk-translation daemon that might range across FMs and fill in all missing translations, without necessarily involving mappers. In the future, possibly AI could tackle that whole enchilada. I was at first visualizing something more modest: a backbone in a standard programming language (I sketched out C++ and C# projects, but lots of other possibilities) that would make calls to an API (I looked at those of Google Translate and ChatGPT). However, I changed focus due to certain concerns... Different FMs, and subsets with each FM, would likely have far better translations if they were properly grouped, ordered, and translated separately, with an appropriate context (e.g., phrase engineering) added. The FM's mapper is best placed to provide this grouping and context. I'll detail what I mean in the next few posts. The mapper would not be expected to know any TDM-supported languages besides English. Instead, each translated phrase could be back-translated to English and examined. Is the "round-trip" meaning OK, even if the English words have changed? Problematic translations could have their context tweaked and rerun. Many AI systems, particularly for API access, require a billing commitment (e.g., credit card). For a professional translator, this is no problem, and subscriptions allow access to more (and putatively better) models and higher quotas. This seems less appealing for TDM. A few paid AI systems have a no-subscription, pay-as-you-go account tier. The cost per translate is typically pennies. But it does introduce quota- and expense-management, and may exclude API usage. Access via API requires an API key (or at the higher end more elaborate security regime), with attendant key-security headaches. Which AI model is thought "best" for translation? Doesn't matter too much, because we can't afford the best. Furthermore, there's endless churn among AI models, with antidotal reports that a given model fluctuates in quality over time, and successor models can be worse than their predecessors. So, with these concerns in mind, I looked for public web-based AI sites that require no billing and provide low-quota but adequate AI. The mapper would enter and retrieve data manually. I will focus on ChatGPT in this exploration, after a quick preliminary test confirmed some promise. Also, as this exploration proceeds, I hope to propose changes to TDM to make it more viable for "sufficient" quality machine translation. Problem areas are incomplete fonts, space-constraints, and layout issues for translated strings. My proposals will likely surface as separate forum threads. That's enough for now. I'll be trying for 1 or 2 substantive posts per week, as I tackle a particular FM.

I guess this is basic stuff for you talented model-boys but now I've trudged for several hours without results and from what I have read in several forums/threads, it's even not that trivial. Therefore I dare to start a thread... I've download some models from the web but these come in some new and fancy format; (FBX, USD etc) not exactly the old and brittle format that we use in TDM So to import these into DarkRadiant I need to convert these to lwo or ASE, right? How do people go about this? I have tried to: - install Blender 5.0 and added an ASE-exporter plugin. Blender actually puts out an ASE-file but as I try to open it in DR, the model is only showed as that checkerboard error-box. Do I need to tinker with the model in a text editor first? I read something about changing something about a BITMAP-line... - use an ancient version (7.0) version of Lightwave but that program cannot even open the files (Not surprising)...

I wish you all a happy new year!

Yes, I also couldn't install it into a fresh directory for the fm. My "patch" process was opening the old .pk4 and new .pk4 in 7-zip, and copying the new contents over the old ones. I only thought to do this because I noticed that the new .pk4 was smaller than the old one. Oh, hey, I didn't notice this until you pointed it out but I have this problem too! Windows 10, en-us locale. EDIT: This also tracks with me being on Windows 10 and not experiencing the water texture bug.

You can ask people to test your mission here, but the beta tresting should be in this other section: https://forums.thedarkmod.com/index.php?/forum/59-tdm-mission-beta-testing/ Read also: I think it's so that there are no spoilers in view for new regular players.

Merging mission archive isn’t supported or recommended, what operating system are you on..? And regarding the bugs - - engine bug, when you resize models. I have now exported as model. - The railings are non-solid and a no-draw solid brush is in place. So what your likely seeing is the limits of the physics & collision detection that I cant do anything about unfortunately. - Fixed, that was a minor oversight by me. - Short of exporting the whole thing as a model in the hopes it might fix it, this is a known quirk of the engine. Both parts of that support column and the capitol are func_statics, so this should not be happening. - it looks fine for me, so I don't know what the issue is.

I just tried v1.1. The new intro area looks really nice and prevents any anticlimactic "insta-KO" approach. Well done! However, I also had to merge the old and new pk4's, otherwise v1.1 would not install. This is how the water looks for me in v1.1: And while we're still in bug fixing mode...

I've read about this before here on the forums, even when the contest had just recently concluded, but reading about it in greater detail years later is certainly interesting. Thank you. It's a pity that it was mostly the marketing people who were involved on the Square Enix side, as I had the impression it was also the devs at EM that had played Requiem and all the other submitted missions and really liked them. I suppose it was as well, but the TDM team mostly heard from the marketing people. Yes, I wanted to note that as well. I even remember how the people over here in the TDM forums were sort of laughing at the fact that the results of the contest were favourable to TDM and had, in a sense, "proven" TDM as a worthy freeware successor to the Thief IP, with all the modding and mapping tools at one's disposal and so on, whereas Thief 4 or Thi4f or whatever Square Enix were calling it at that point, offered no such possibilities. The entire contest, while no doubt declared in good will and something I actually appreciated seeing, was such a self-own for Square Enix, ultimately to the detriment of them trying to bring back and market the reboot of an older IP. Even if Thief 2014 was a terrific reboot (which I doubt it would ever be), it would still have been hampered by people learning about modding being impossible, and looking to the trilogy and to TDM instead, to make new Thief-style stealth gaming content. Still, I appreciate they recognized the quality's of Moonbo's Requiem FM. Given many retrospectives I've seen over the years, gradually, on the 2014 Thief reboot attempt, one thing a surprising amount of them shared was noting how the game didn't feel cohesive in concept and execution, at any point. Not only not to the same level as the Thief trilogy, but also not even at the level when you consider it as an individual game, a new game on its own. Errant Signal, who's not some deep Thief fan, replayed the older games and played the reboot back when it came out, and made this exact observation already a decade ago. The reboot was just all over the place, in every department, felt clearly unfinished or rushed, and the most interesting story would be the behind the scenes at Eidos Montreal, on how mismanaged the entire project became over the course of several years. I think it's telling that, while even heavily discounted on GOG.com, Thief 2014 hasn't been selling well there, nor attracting much interest, whereas the original trilogy sells for figurative (and sometimes literal) cents on that same site - you can buy the whole trilogy for a smaller price than the reboot, which is kind of hilarious - and continues to have great sales and is considered one of the all-time bestsellers. Same here. I concur with demagogue that the actual Eidos Montreal devs behind Thief 2014, at least those who cared enough to make it at least somewhat presentable and playable - even if the actual game directors never got their act together and never decided on a consistent design apporach - those would have been much more interesting to be in contact with, even regarding the fan mission contest. The sad truth of the matter is that all too many big publishers these days, especially those formed through larger mergers, like the Eidos buyout by Square Enix, are often marketing-first, interest in developers, and veteran players and new players alike, second. I still remember the sheer amount of money spent on pointless external marketing for Thief 2014, all the while that reboot attempt never really coalesced into anything that felt consistent (rather than throwing everything at the wall, in a panic, hoping something would stick), and was also plagued by all manner of technical issues. Just an overall embarassment, and I'm not surprised that even very lenient-leaning game retrospectives of that reboot attempt. The fact that the Thief IP has been sold away to Nordic Games and Embracer in more recent years, with Square Enix no longer caring about it and other older game IPs, also says a lot. Given the Embracer Group's own woes and bad decisions, I'm not sure any new development team will ever attempt another installment of Thief, even if it was a second reboot attempt.

http://i1049.photobucket.com/albums/s390/sirtaffsalot/vfat3_2015-02-16_18.15.48_zpsdf13cqmi.jpg UPDATE: This is now a Campaign Pack courtesy of Datiswous: https://www.thedarkmod.com/missiondetails/?internalName=vfatc What is The Complete Vengeance for a Thief Campaign? The Complete Vengeance for a Thief Campaign is a three part campaign with a brand new installment at the beginning called The Angel's Tear. The other two installments are the previously released A Pawn in the Game and The Art of revenge with new areas, additional story plus bug fixes and performance tweaks. What are the new areas in A Pawn in the Game and The Art of Revenge? Pics The Angel's Tear: New areas for A Pawn in the Game and The Art of Revenge: Download links: http://www.mediafire.com/download/c2p0myxp32hb8sb/The+Complete+Vengeance+for+a+Thief+Campaign.zip Installation instructions: Unzip the zip file and extract the three pk4s to The Dark Mod's FM folder. Load up TDM and play them in order. Thank you to the following: Bikerdude for help with visportals in the original A Pawn in the Game, visuals in The Angel's Tear plus all the mapping advice and tech support he has kindly provided me with over the years. Beta-testers for The Completer Vengeance for a Thief Campaign: AluminumHaste, Oldjim and Cookie. Beta-testers for the original A Pawn in the Game: Grayman, Bikerdude, Nbohr1more, Ppoe and Xarg Beta-testers for the original The Art of Revenge: Gnartsch, Obttorte, Lux and Jaxa. Everyone who helps me out in the Edtors Guild of this forum. Special shout out to Sotha, Grayman, Obsttorte and Bikerdude. Apologies if I've forgotten to mention anyone. The TDM team for providing me with countless hours of mapping and gameplay fun. Everyone who contributes anything to TDM to help make it the awesome mod that it is.

Downloaded the new version to look at the new intro area (felt like I ought to do so because... I asked for it). Looks nice! Also, starting the player out there gives the builder priest time to get a bit through his patrol path so he becomes much more of an interesting AI to deal with, and there is some context for why he instantly attempts to wallop the player on sight. I did not notice any issues with the water texture in the cave - but I had to do a slightly weird process to update. Krampus_1_1.pk4 by itself didn't seem to correctly load for me in TDM, and I noticed it was about 10mb smaller when I downloaded it off google drive. Seems like you forgot to reupload the briefing video or something? So I dragged and dropped the contents of the 1.1 pk4 into the original .pk4 and then everything worked. Maybe I just managed to preserve the functional water texture somehow or something. I was still able to open the offetory box from the wrong side, but I had to really try to make it happen so I'd say your attempts to block it are good enough. If I wasn't frantically frobbing every pixel of the box to try to break it on purpose, I doubt I would have noticed on a casual playthrough. Another tiny nit I found, while I was trying to see if I could bug out the cave water texture somehow: there is a patch for dirt underneath the water in the cave that obviously ends a little bit too early. I've attached a screenshot of the seam I found while I was swimmin' around lookin' for loot.

Happy to hear you found a solution! I'm glad you posted this though because I actually learned something new about model scaling with that wiki article you just linked. I didn't know you could scale models in one dimension only

Author Note: Thank you for downloading and playing the sequel to The Accountant 1: Thieves and Heirs this FM picks up right from where we left off in accountant 1. This is the second part in my three part series following Corbin on his journey to discover who and what the accountant is. This mission is a little different to what you may expect from a Thief mission but still has plenty of classic Thief moments as well. This is the largest mission I have ever built with an average play through lasting between 2 - 3 hours. A few aspects in game are different to what you may expect as well and those are: - Candles are pinchable (frob to put out instead of pickup) - Food has been hot fixed so now it heals you for 10 health points when eaten - Doors that are missing handles means you cannot enter that room/building - All secrets can be found before you enter the sewers As a little piece of fun trivia there is a small cameo in my mission from a very special guest. He is a longtime voice actor in the industry and you may know him from roles such as Deckard Cain in Diablo, Captain Price in Call of Duty, Elder Lyons in Fallout 3, or just about any Nordic character in Skyrim. In addition to all of the fantastic people who have helped me along the way I have personally spent a lot of time, effort and energy devoted to bringing this out to you all so I hope you can enjoy the fruits of my labor and have fun! File size: 358 mb

Contributions downloads are at http://fidcal.com/DarkMod/index.htm Note that there is no dedicated beautiful sortable webpage list. I don't have time and also this means less delays. Just browse the folders and click on readmes and images and grab any zips. If anyone submits anything I can just upload it in a few minutes. ~~~~~~~~~~~~~~ If you wish to offer coding, modelling, or any other kind of help got to the I want to help forum for discussion. If you have any extensive assets you wish to discuss also you can go to the I want to help forum. If you simply want to share an FM, prefab(s), textures, whatever then post details in this thread (there are other websites for FMs too.) Generally these need to be zipped up with a description.txt plain text file and optionally an image, and uploaded somewhere I can get them such as a fileshare website like rapidshare. Any problem with that and if you have ftp I can arrange a direct upload to a private temporary folder on my website. All submissions to this thread should be accompanied by a short description summary to go on the download page and optionally a picture(s). Such submissions will be placed on my website download page (wip) at fidcal.com. Anything suspect for any reason I reserve the right to delete. I accept no liability for downtime or even no-continuance of the download section or even the entire website for any reason. Downloaders: I accept no liability if you download anything you'd rather not: download at your own risk. Oh yes, and I am not responsible for global warming, economic depression, you name it; I'm not responsible. From there, any mappers can download what they want. The Dark Mod Team may or may not assess some items for inclusion in future Dark Mod updates. FMs may be assessed for inclusion on the Dark Mod website. Anyone feel free to mirror the download folder. Any suggestions post in this thread too.

Lately I have started to play some of the more recent missions and some of these have lots of "own"/unique textures. Is it okay to use these assets (from released FMs) in one's own FMs? I'm referring to models/textures and sound etc, of course not chunks of the mission geometry or blatant plagiarism of readables etc. I guess some people have designed or bought assets for themselves but is it okay to use these textures/models as long as there is no explicit note in a readme etc, that opposes such "borrowing"?