Search the Community

I'm also not a fan of the limited inventory, especially because the first place to store some items in a chest is at the current end of the playable area, which, in my case, is 8 to 10 hours into the game, so, pretty late... I also don't like fixed save points/rooms, which require a lot of backtracking if you don't want to lose your progress, when you do a mistake like falling from a ceiling, or alerting 5 or 6 guards at the same time, which can easily happen. It seems like a silly restriction, which adds nothing to the gameplay. Other than that, as I said, I'm really impressed, and, I also like that the game doesn't explain you the whole game in the first 30 minutes. I think that's an unfortunate development in modern games, and it's refreshing to see games like the System Shock remake and this one getting rid of that hand holding. Because, sorry, that's basically what it is. Unless something is super unclear, it's really not impossible to figure those games out yourself. That's a big part of the fun and appeal of them for me.

I've been wanting to post this topic for many months now. It's a continuation to ideas I posted a while back, regarding my wish to create a total conversion for TDM, adding a cyberpunk theme alongside the original steampunk world. The reason for making a new thread is that I have a plan laid out by now, but will need help from the community with it. I wish to know how many people would be willing to help out, so that I may know whether I should start laying out the foundation of this project. I will explain exactly what I plan to do in the form of a FAQ below, so that I can easily cover every aspect. This is going to be long, so make sure you have some time before diving into it! If you want to go straight to the points about what I require and skip the rest, read the titles in red which cover the essential paragraphs. What is this all about?The idea is in part inspired by one of the favorite games in my childhood, DeusEx - The Conspiracy. I used to spend weeks playing through it every few months, drawn by its adventurous story and its dark yet appealing environments. Since the last few years, it's been a dream of mine to create a FOSS cyberpunk stealth game with RPG elements, that would be entirely unique (similarly to how TDM is unique from Thief) yet have the same feel and atmosphere I loved about it (once again like TDM has the same atmosphere as Thief). My earliest thoughts were on trying to achieve this in Xonotic, which is a GPL licensed arena-type shooter I've been a long time contributor to. Of course I eventually abandoned the idea... mostly given that Xonotic has no features for single-player mechanics, such as saving / loading or any kind of AI except bots treated as real players. Then more than two years ago, I finally discovered The Dark Mod. After playing it for some time, I quickly realized it's by far my best option to making such a project come true. Why The Dark Mod, instead of building the game from scratch? It was designed to be a steampunk stealth game after all!The first reason why I want to use TDM as a basis is that it already has every crucial mechanic I need, in terms of AI and interaction and world programming. It does of course lack a lot of the features I ultimately hope to include, although most are optional and I could attempt scripting them at a later stage... for now little to no game code chances would be required. The most significant features are the AI (very advanced and intelligent), carefully balanced gameplay plus other common ideas, as well as the mapping system with its intelligent area portals. It should also be considered that while I'm usually a competent contributor, I'm terrible when it comes to programming something from the ground up, so there's no other way this could happen as a FOSS project unless I hire an entire team. The project aims to be a stealth game that works the same way after all, so why not? To exemplify what I mean: You can open DarkRadiant and build a medieval town with a tavern, then add a guard patrolling the tavern with a bow and a sword. In the conversion, you'll be able to build a futuristic city with a club, and have a guard patrol that club with a knife and a rifle. In both cases, the AI will do exactly the same things with equally correct results: The guards take the same patrol routes, chase after the player the same way, vocally alert one another in the same fashion, and search rooms and hiding spots as efficiently once the player disappears from view. There is no "medieval patrol style" versus "futuristic patrol style", the choices and decisions are exactly the same! The only considerable difference will be the assets and animations and settings. The second reason is that I'm a fan of the idTech engines as well as gtkRadiant based editors. idTech 4 is in fact one of my favorite engines in the line, due to how intuitively it was designed at its core and how much it pulled off during its day. Its only problem is that it hasn't had as many developers forking and modernizing it, unlike idTech 3 with say Daemon engine (for Unvanquished)... that is of course not its fault, and in part due to being open-sourced much more recently in comparison. How exactly would the mod work? Are you thinking of creating your own TDM fork?I don't plan to create an actual fork of TDM, which would be impossible to maintain on my own and only divide the community and its efforts. My plan is to create a mod that will run on top of vanilla TDM, adding new content without affecting any of the existing functionality. The mod would be distributed as one or many pk4 files, which are simply dropped into the main directory next to the stock pk4's! Its assets will be grouped under the mod's own name, so that they're always distinguishable from the normal ones... just like every default component is listed in a "thedarkmod" directory inside DarkRadiant, they would be listed in a "howeverthiswillbecalled" group. Once you have the pk4(s) of the mod inside your TDM installation, normally download any mission using them it in order to play it! So missions will be able to use entities and assets from both stock TDM and this mod?My plan is to allow that, and nothing should prevent maps with mixed assets. Keep in mind however that I ultimately want the mod to be independent, and encourage relevant missions to only use textures and entities included with it rather than a mix! If you take out every single stock TDM asset (excluding md5anim's which will be reused) the mod will be expected to work on its own. Will the new assets also be non-commercial?Unlike vanilla TDM, I don't wish to include any CC-*-NC and CC-*-ND assets with the mod. That's primarily because I find them limiting, and feel that they ruin the openness of the project. Is there a name for the mod yet?I've been thinking about it but haven't fully decided so far. I want it to be something familiar and related to TDM; Initially I wanted to call it The Dark Modern, but that sounds rather silly. The name I'm considering now is The Dark Machina, which retains familiarity with TDM and is also more theme relevant... further suggestions are appreciated. What is the benefit for the community? Why should anyone put any effort into this?The project is targeted to everyone in the TDM community who alongside a steampunk stealth game, would enjoy a cyberpunk stealth game of equal or greater visual fidelity... with exactly the same base gameplay and core functionality, but an entirely different world and atmosphere. The project will be publicly available on a Git repository of its own (most likely Gitlab), and anyone will be able to easily install it on top of vanilla TDM. Simply put: If you help and things go according to plan, you'll have a triple-A scifi game inspired by the look and feel of the DeusEx series, just as you currently have a triple-A game victorian game inspired by the look and feel of Thief. What do you need help with exactly? What would others have to do?Obviously I'm not asking others to do the work for me. But at the same time, it's not something I can just go ahead and do on my own either! For this reason I've come up with a plan, which would allow contributions to happen gradually whenever someone willing to dedicate their time to helping adds something new. This is mainly a call to existing TDM developers, who know best how to export and define new assets. If the project takes off, based on the answers I get in this thread, the starter plan is as follows: I will be creating two Git repositories. One will be the official repository of the mod, which will contain assets in working format and condition... the other will contain images, sounds, blend files, and other resources in their native format. This will include freely licensed assets I find on the internet, which I will hand pick and tweak to make sure they're in the readiest state possible, then sort them in a way that's easy to work with. Most will be taken from http://opengameart.org and http://www.blendswap.com and I'll likely use a few things from Xonotic altogether! The assets included in this repository are to be exported and / or converted to TDM compatible formats, then included in the real mod repository. A list will be maintained in order to keep track of which assets have already been ported. Every ported asset can be issued as a pull request, or sent to me personally in case the contributor doesn't have access to the Git service that will be used. The rigging, exporting, and conversion processes are what I require the community's help with! As far as models textures and sounds go, no new content will need to be created... I plan to use freely licensed resources which are already available and plenty, enough to create a full mod out of. Obviously I'll be doing some of the exporting and definition writing myself, but since there will be so much new content I can't do it all on my own... unless I dedicate every waking hour of my life to it for over an year, which would be more than I can handle TLDR: I'll be compiling a repository of game-ready assets, such as textures and models and sounds. Anyone who wishes to help is only asked to pick them up, adjust the TDM specific necessities (exporting to md5, creating material definitions, etc) and publicize the results for inclusion. So no new content is going to be needed?For the most part, no. There is only one exception to this rule: Voices. As they're something TDM specific, they have to be created to match the world and what's happening in it. They are however not a priority, and can happen at a later stage in the project. Until then we can live with a few cyborg troops saying things like "in the name of the Lord Builder, you shall go to the gallows, you heretic" Other than that, I will eventually want to add new functionality. Including a Minecraft type inventory system, computer chips the player can install into their suit or body in order to gain enhancements (modules / augmentations / whatever), and most importantly a re-implementation of the interactive touchscreens in Doom 3. Those are however even more distant needs in comparison, and not what this thread will focus on at this point... I plan to look into such once I'm sure there are enough contributors to be certain this is happening altogether. What do you need done for each type of asset explicitly?Here is a list of every new asset type the mod is going to introduce, and the steps I estimate to be required for each: Characters: I will be offering the blend files of all characters scheduled for inclusion. They will contain the mesh, textures, as well as the rig that the character comes with (if available). Steps to be taken include: Rigging the character to the TDM animation skeleton after using the original rig for initial posing (including face rigging), generating the shadow mesh, making sure polygon count is within acceptable limits, and finally exporting to md5. Lastly, generating and tweaking the character definitions (stats, team, social status, voice, etc) and the material definitions for the character's textures, which should be all that's needed for the model to become a working character. Notice: I'll be preparing a blend file containing the simplified / optimized TDM rig in order to ease the process, including the face rig which I remember had to be extracted from existing characters. Models: A similar process would be needed with static models and simple entities: They will be distributed as blend files which include the model and texture, and need to be exported to ase / lwo, with entity and material definitions in place. Textures: Most will likely be distributed as jpg and png, and will need to be converted to dds and tga. The material definitions will need to be created as usual. Sounds: Will be distributed as wav or ogg, which normally don't need to be converted. Sound definitions need to be created however.As far as specific TDM functions go, this is how I intend the modifications to work per component: Weapons: The plan is to keep each weapon the same in terms of purpose and functionality, and mainly modify the models animations and sounds. The same core code will therefore be used by each, but new entity definitions should be made in order to not affect maps using the existing items while the mod is installed. Menu: When a mission intended for the mod is installed, the main menu will use different textures and a different background song... no modifications to the entries or functionality will be made otherwise. I'm uncertain as to how this can be achieved, although it is lower on the priority list.What will be the modern equivalent of existing TDM items, as well as new content?Like I said, I plan to keep the functionality and purpose roughly the same, at least for a while. Therefore items will serve the same goals, and work almost exactly like the existing ones in TDM... it will be basically the names and appearances that change. The important replacements I currently have planned include: Weapons: Blackjack becomes Police Baton or Taser. Sword becomes Knife. Bow becomes Crossbow or Sniper (arrow types and behaviors unchanged). Items: Lantern becomes Flashlight or Keychain Light. Telescope becomes Binoculars. Compass remains Compass. Snake and Triangle lockpicks become Physical and Electronic lockpick (mechanical doors are unlocked with the first, electronic doors with the later). Potions become Medkits, Syringes, or special types of enhancements.As far as completely new content goes in regard to items and entities, here is a rough list so far: Books & Notes: Alongside the existing books and notes, laptops / smartphones / tablets will be added. They are unrelated to future plans for interactive screens, and simply refer to new types of visuals for readable items found throughout the world. Lighting: The replacement to existing candles and torches will mostly consist of desk lamps, particularly neon and LED based ones. Characters: A similar structure of factions will be followed, compared to the existing guards + thieves + civilians + beggars + nobles. In this case the main categories will be: Police (ideally different suits for various units), gang members (once again different clothing for each gang), with modern looking civilians of various classes. There will also be entirely new outfits covering jobs existent in modern times, such as scientists or industrial workers. Robots: The existing code behind the Steambot will be used to implement multiple kinds of security drones patrolling an area. Especially in early stages before new scripts are considered, they can have the same function of only sounding an alarm when the enemy is spotted. Props: There will be various modern props added throughout the world, depending on what content I find. This will include: Flaming barrels for poorer areas, futuristic cars and bikes parked on the sidewalks, televisions that play videos (in case itTech 4 allows video textures), and the list goes on.Closing thoughts:First of all, thank you for reading this enormous post, regardless of whether you wish to support the project or not. This is something I've dreamed of creating for a while now, and I really hope at least a few artists out there are willing to support it! Please leave your thoughts if you want, as well as voting on the pool so I can more easily estimate the help I may expect.

We will look at some of this stuff, but SPOILER tags, please!!!

This may make sense in that the performance impact of the volumetric effect can scale with how much of the effect is filling the screen. We shipped with a “performance mode” but had to setup the entities by hand to do it (so it’s not perfect). If you change the LOD detail settings to “Low” or “Lowest” this will disable certain lights, particles and such that can be very heavy to render. You can try these settings and see if you notice an improvement. If not sending us some pictures of heavy areas (with spoiler tags please) will be helpful with tuning these “performance modes” in subsequent patches. Thanks for playing!

This is something I wanted to try implementing myself more than an year ago, but ultimately figured it's overly advanced engine stuff for me: If no one else wants to I may still attempt it someday, in the meantime I wanted to write and ask about it at least. I don't know if this was previously discussed and I hope I'm not repeating something old: I've been seeing all the amazing changes done recently like volumetric lights... watching how far TDM has come makes me excited to see it get even further and become even more amazing. One of the last remaining renderer features I feel we're missing is the Depth Of Field effect. I do believe having this would make every environment in each FM even more incredible and realistic, while bringing TDM even closer to having top notch visuals on par with most modern engines (if we exclude PBR materials). Existing shaders and tutorials for the GLSL implementation are out there possibly even an existing idTech4 port; Initially I hoped it might be as easy as grabbing a freely licensed shader and integrating it in the engine, but usually things are always harder in reality. For starters I'm curious if others are with me in wanting this, if there are any plans for adding the feature, and if there remain any major roadblocks in the engine preventing it... engine wise I know the shader just needs access to the Z-buffer and can typically work its magic from the depth map. The best implementation I'm hoping we can get is the dynamic one, which smoothly adjusts focus based on where the player is looking (distance of the center pixel in the middle of the screen). By default the effect definitely shouldn't be excessive, only blurring distant or near things very slightly unless you're looking at a surface right in front of you. I don't believe it needs to be enabled by default as long as it's in the menu, like the sharpness filter it shouldn't bother anyone who doesn't want it and make things look beautiful for those that do.

Is this the right place to suggest including a mod? If so I'd like to propose the keypad I made: The mod introduces keypads that require a code to unlock, eg: 1337 then press confirm. Comes with two versions: A modern looking one (supports typing words in SMS style) and a steampunk variant that looks older and worn out, both use existing textures and only include simple models for the keypad body and buttons. Created for a somewhat scifi campaign I'll likely never finish and I'd like other mappers to easily find it and benefit from this too.

After a long time and a lot of delays, I'm extremely happy and relieved to announce the release date for my first map; Lords & Legacy, on Friday the 30th of August, 2013! Lords & Legacy v.2.1 Resume: Screenshots: http://imgur.com/a/Lj8UJ#0 Notes: Build time: 2013/03/30 - 2013/08/30 To install, simply put the .pk4 file in your fm folder and install from the in-game mission menu. It is a large mission with optional objectives, so make sure to save often. The ropes in the beginning have a 'slick' surface, to simulate being 'slack lines'. They are difficult, but once you get a hang of the slide they can be fun. A couple of the large areas can be a bit rough on performance, and can be improved by adjusting the LOD slider in video options. A few of visportals open only when you get close. This is to keep the frames smooth inside the respective building, due to early inexperienced design. If you find any bugs which affect the gameplay experience, then you're very welcome to post them here, but please use the spoiler tags. Big thanks to 'Obsttorte', 'Springheel', 'Greyman', 'Bikerdude', 'Sotha' and rest of 'The Dark Mod Team'for all the help, guides and tricks. Also thanks to the other TDM users who provided fantastic support and feedback during the build. Thank you for beta-testing: 'Bikerdude', 'TylerVocal', 'Simplen00b', 'nbohr1more', 'Briareos H.' Special thanks to: 'Danus', 'Dsx' & 'Stanleh' for testing, help and support. v.2.0.1 changelog: Bugs: -The "Master Thief" challenge was impossible to do for a while, due to incorrect values. Fixed. -Getting seen by "The Killer" now also fails the "Ghost" challenge. -The 3 cardplaying guards no longer float mid air, as their chairs are now nailed to the floor. -Fixed the sound of the furnace continuing after the flames were extinguished. -Fixed weird glittering on the power cables around the map. -Fixed some moonlight popping in and out. -Fixed openable windows in Commons, clipping into the frame. -Fixed a book dropping through a desk. -Fixed visportals closing too close in Lancel's Tower, slight hit on performance though. -Added more monsterclip to Service Tower and Robert's Tower's entrance. -Improved a few vis_portals with func_portals. -Replaced curbs in Slums and Commons with some more detailed versions and changed textures. And a lot more little unecessary tweaks. Gameplay: -Added new challenge: (Jack White) - Do not knock-out anyone. -Reduced the amount of starting gear, depending on difficulty. -Added cubemaps to most windows on the map. -Redid most func_statics in Commmons Quarter to reduce tris and increase performance. Draw count is still somewhat high. -Removed all transparent windows as they didn't have actual gameplay value, just a performance drain in exchange for glitchy visuals. -Lancel's safe can no longer be picked. Find the key! -Added a couple minor cosmetic details in the sewers. -Moved a coinpurse from a wealthy commoner's sleeping butt to his nightside table. Also adjusted his furniture so thieves can better move around. -Changed sounds for several doors across the map. Once again, a big thanks to 'Bikerdude' for taking the time help out and locate room for improvement! v.2.0 changelog: Bugs: -Fixed various textures and surfaces and a few minor tweaks. -Tweaked some sounds to be in line with TDM 2.0 changes. -Fixed 2 certain AIs being too sensitive rather than drunk. (Thanks to AluminumHaste!) -Tweaked LOD on some objects, to prevent windows "popping" in and out. Gameplay: -Added more monsterclip to the towers, so the AI can now run up and down stairs. Only the stairs in the small tower has issues still. -Added more monsterclip in the city so the guards can follow you up all stairs. -Added a few minor details. -Windows in the city now dims sound, resulting in less aggro from guards and more convincing soundscape. -Reduced 'draw calls' in all the large areas, increasing performance. The map is still heavy at certain areas. Another big thanks to 'Bikerdude' and 'Greyman', for taking time out of their own schedules to help optimize the map's draw count and other significant adjustements! v.1.0.3 changelog: Bugs: -Fixed 4 black chairs in one of the towers -Fixed a floating painting -Fixed several clipping objects v.1.0.2 changelog: Bugs: -Fixed zfighting in the library's bookshelves -Fixed a black window in one of the towers -Fixed several typos in readables Gameplay: v.1.0.1 changelog: Bugs: -Fixed an issue with the main objectives not being in "sync". -Fixed console spam from a script Gameplay: -Adjusted required loot for each difficulty from "3000, 4000 and 5000" to "2500, 3500 and 4500".

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Public release v1.7.6 (with Dark Mod support) is out. Improvements since the final beta 14 are: Fixed a few remaining bugs with zip/pk4 support. Game Versions window now properly displays TDM version. Import window no longer has a vestigial off-screen TDM field (because TDM doesn't need or support importing). Web search option is now disabled if an unknown/unsupported FM is selected. If an FM with an unknown or unsupported game type is selected, the messages in the tab area now no longer refer to Thief 3 ("Mod management is not supported for Thief: Deadly Shadows"). The full changelog can be viewed at the release link. The de facto official AngelLoader thread is here: https://www.ttlg.com/forums/showthread.php?t=149706 Bug reports, feature requests etc. are usually posted there. I'll continue following this thread though. Thanks everyone and enjoy!

For my comming modern-time themed FM "The Dark Mission", i would like to add modern weapons. The weapon that I have in mind is the Fort 12 from RWM Pack c (a replacement for d3 pistol) (And when it is working, i'm going to change the object, so it doesnt use proprietary sound, textures, etc.) At this moment i only can spawn the weapon and cannot pick it up or use it . The console show some things that the weapon needs, but cannot find it in the d3 pak files. I hope you can help me. I installed the weapon by copying RWM_Pack_æ.pk4 (from rwmpackc) and pak001,2,3,4 and 8 (from d3) to the folder of my fm. my log spawning and giving the fort 12 (replacement for pistol) Weapon in action: .

heh i was thinking the same though it might just have been a glitch when writing the names are pretty similar. But for correctness it is called the dark engine and the newer version that allows us to run these beauties on win10/11 is called newdark. newdark is kinda interresting as it just suddenly popped up on a french forum some time ago by an anonymous developer with the alias le corbeau who allegedly got his hands on the original source code and started updating it for modern OS. this was the original thread i believe -> https://www.ttlg.com/forums/showthread.php?t=140085 bikerdude was on that forum to when the patch hit i noticed hehe.

Good work! I enjoy short missions because things are nice and focused - you get in, you get out. Also I tend to do better with the loot amounts and I was able to get all the loot without too much trouble, which is rare for me. If I were to make a suggestion though - I found the intro briefing sequence a bit distracting because it was so obvious the narration was pitch-shifted to make a deeper voice. If you felt the original voice wasn't deep enough for your needs, I would either get someone on the forums to record it for you or just leave as is. That's my only real complaint and it's not even about the mission itself, so pretty good first start!

I am pretty sure there is a good reason for using the DOOM 3 engine, but it does make me wonder for how long this project can remain active if it doesn't get transferred onto a modern game engine eventually. Although I am afraid that if it gets transferred to a modern engine, the temptation to make everything look photo realistic, will take away its retro-aesthetics-charm.

I am pleased to announce the release of our new fan mission, The Hare in the Snare: Part 1 Mission type: City Missions + Inn/Tavern Description: People are being abducted off the streets and a Watch Captain requires the services of a thief to help him find out why. Download link (v1.0.2-release): https://drive.google.com/file/d/1HYvM_u56wDB16uIlb7qgS_q3P24V69MO/view?usp=sharing Credits: Mapping and original characters: @Frost_Salamander Story, readables, custom models, voices and cinematics: @Kerry000 Menu title track produced and mixed by @JackFarmer with selected gigagooga sound samples Beta testers: @Cambridge Spy @Zerg Rush @Amadeus @Acolytesix @Lzocast @wesp5 @nbohr1more @Kerry000 @ate0ate @Wellingtoncrab @prjames Additional thanks: @Dragofer, @nbohr1moreand @peter_spyfor technical help @Springheel for the modules and tutorials @kingsalfor allowing @Kerry000to abuse his manbeast everyone else on Discord and the TDM forums who offered assistance Requirements and notes: This mission requires TDM 2.09. Earlier versions will probably work but you might see one or two missing models. You may experience some FPS drops in some areas with lower-end hardware. Mid-range and above should be fine. If you have issues, I highly recommend you use shadow maps instead of stencil (settings -> advanced -> shadows implementation). It makes a big difference. For 'Hard' and 'Expert' the light gem sensitivity has been increased by '1' (meaning easier for AI to detect you). Screenshots:

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

Though this is related to PBR as a component in getting it done right (like reflection probes) I thought it's an improvement of its own that's worth discussing. I don't know if this is implemented or estimated in some form, but working with light entities in my own FM's I haven't seen any spawnargs for it so I presume it's not. At the moment lights in TDM act as zero-scale points, light sources have no actual radius. I know what you might be thinking: Of course lights have a radius, it's the box that decides how far a light shines and what it affects! What I'm referring to is not the range but the emission radius, representing the scale of the bulb itself: Think of it as a minimum radius... at the moment lights only have a maximum radius, the minimum is currently a point. In modern engines this affects both specularity and shadow softness as well as how the light is distributed. Like most engines we shouldn't need anything more than a float describing the size of the bulb, a simple sphere ought to be enough... given we already work with radius boxes, we could instead use a separate box which would give us better control with unevenly shaped bulbs. Every default light entity should of course be updated to use this: Torches / candles would set it to the average size of their flame particles, gas / electric lamps should have it represent the scale of the light bulb or the lamp head. If done right this can greatly improve our graphics and add more realism, but as with most things it's not going to be that simple. Also this would create changes to the lightgem in all FM's but very minuscule ones that shouldn't even be detectable. There's 3 different components I presume we have to tackle independently. Soft shadows: Shadowmap softness is probably the easiest, just add the average bulb radius to their value. Specularity: At the moment all lights seem to produce specular orbs of the same fuzziness on shiny surfaces. What we probably want is for lights that keep their min radius 0 to produce a fully sharp orb or dot, softness is added to each light's ball based on this radius. Light projection: The biggest aspect is changing how light is distributed, the projection texture / falloff material would emanate very differently. Everything inside the bulb would shine at the intensity of the center pixel and should start fading from the min radius toward the max, the projection texture would get slightly inflated like a balloon. The best solution (which also accounts for blur) seems like a 2D shader that copies the light texture onto itself at slightly different offsets to make it fuzzy: There's already a blur filter that does just that when you're underwater for example, we could to get away with doing the same thing to light textures using the min radius as the offset parameter. As lights typically don't change scale, this should be possible to do only once at map start rather than every frame including for moving lights like torches, this way we should have no performance loss.

That indeed sounds useful, but those Eevee renders do seem to be more advanced than what TDM can do, like those reflections and shadows, seem to be way ahead, is that really simple OpenGL lighting? Seems more like some kind of modern PBR system.

I'd like to better understand what you want. The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players. Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar. https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580 "tdm_frobhold_drag_body_behavior", default:"1" Which drag body behavior? 1 --- on frob key up, drop body (limb). 0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior. That cvar was removed shortly afterwards, because it was said that it wasn't needed. With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back. Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

@MirceaKitsune I don't say this to be discouraging, but a developer has already responded that replacing the AA in the game is not arbitrary and has no ETA so not sure what else you are looking for? Even if the engine is overhauled to the point TAA is an option, there is still no perfect AA solution. The image quality of the most modern games often reveals shortcomings under scrutiny - there are always trade offs. So how helpful is your suggestion which paraphrased is basically: "we need a bespoke AA solution that cheaply provides perfect results" when it comes to actually solving this problem? In a game where the image is typically dark and there isn't much high frequency detail it does not take much AA to provide an acceptable image in 95% of circumstances imo. It is we mappers who ultimately control what you are seeing in a given mission, and these scenes in SLL are very brightly lit with large volumetric light volumes. This for example reveals a lot of limitations in the resolution of shadow maps for these lights and presents normal map interactions that are not typical for the game, all that were quite obvious in development. Ultimately we liked the overall effect, so we accepted the trade offs. While there will always be room for improvement and advancements (just look at the VL light quality improvements coming from 2.10 to 2.11) it is that overall presentation, including those compromises, that is what real time game art is all about.

I don't think anyone's going to just randomly come up with a better alternative to SMAA. That would take serious knowledge of this particular domain and probably a lot of research and experimentation. TDM is not currently in a state where we can implement TAA well, because good modern variants (including FSR 2) require motion vectors, and we cannot currently create proper motion vectors. Even then, it is by far the most complicated technique to implement well. So, realistically, that leaves FXAA or SMAA. Personally I think FXAA is terrible and not much more than a glorified blur filter and would be a complete waste of effort. SMAA is at least ok in some sense, though for me absolutely not a replacement for MSAA.