Search the Community

Changelog of 2.14 development: dev17330-10984 * Tonemapping is now applied to game frame only, HUD and menu are not affected. Includes major & breaking changes in X-ray implementation (6606). * Now engine defines macros TDM_VERSION/TDM_REVISION/TDM_VERSION_FULL in game scripts and GUI. * Added all missing mipmaps in DDS textures (post). * Fixed crash from having many localization packs (6611). * Fixed comments parsing and automatic collision model for OBJ models (6610). * Ported some fixes from dhewm3 repo: save/load, snprintf, bad memset, some RenderSystem shutdown fixes. * Fixed number = 1 in inventory GUI on non-stackable items (thread). * More fixes in fonts (post). * Added cvar r_ssao_insubview which enables SSAO inside subviews. * Split oversized tdm_modelsXX.pk4 packages into more pieces. dev17332-10999 * Fixed Linux crash when material with custom shader is loaded during gameplay (6510). * Completely disabled old light estimate system (6546). * Now it is possible to use larger mesh models... at least static ones. * Ported some more fixes from dhewm3 repo: mostly warnings and uninitialized memory use.

Of course. The depth hack works as intended and basically stops weapons and weapon attachments from clipping through the map geometry. I confirmed this by setting it to false in the engine code and noticed that the weapons/items clipped without the hack enabled. I think the issue happens when an object is fully outside of the map. You can see this if you "noclip" to an out of bounds zone, the weapon will stop being rendered. So, when the player leans against a wall, the items in the hand, which are fairly small, will be completely outside of the map and thus stop showing on screen. To fix this, I simply added a square plane to the object model to make it bigger than it actually is, and added the "nodraw" texture to this plane so it wouldn't be visible. This way, the object is big enough that some part of it is always inside the map, forcing it to be rendered. The easiest way to add this invisible plane is by exporting the object model we want as an ASE file in Dark Radiant - so we can open and change it - and then manually adding the geometry and material of the plane to the file. I edited the first item in blender to add the invisible plane and then saved its geometry and material in a template file that I can now use to just copy and paste to any new models I want to add to the mod. It seems to work well. The only important part is exporting the model in Dark Radiant with origin at "0 0 0", since the first plane was created for an item with that origin.

The Glenham Tower is a small/medium sized map in which aspiring thief Thomas Porter sets out retrieve an old book from a derelict tower. Mission was created by me, Sotha and I wish to thank Melan, Fidcal and Bikerdude for playtesting. After I busted Lark Butternose out of the Old Town Jail (please see mission: The Beleaguered Fence) I hid and waited for Lark to regain consciousness. When he learned how he got out he was quite happy to offer me a significant portion of his share to our loot. After that our business was concluded and we went our separate ways. I heard Captain Godfrey Knighton was not at all pleased with the events at the Jail and was still looking for the people who robbed him blind. I decided to disappear and move north to a town called Braeden until things calm down in The City. After looking for work via the usual channels, I was approached by a bookstore owner named Victor De Grenefeld. He offered me a simple and entirely legal task of retrieving a rare old book from a derelict tower. The Glenham Tower was originally built by a wealthy family to provide a safe and secluded place to reside in the misty Glenham Moor. The family was disgraced by some kind of scandal and the Tower was later bought by a hermit scholar named Lord Morley who moved in with a single servant. Lord Morley, I learned, was doing some kind of research for the Builders. Some years ago the inhabitants of the tower simply stopped visiting Braeden anymore to buy supplies and food. The tower was found abandoned and sealed. The original residents, in fear of robbers, had installed an indestructible portcullis which was now closed and there was no way to enter the tower. Many have tried to force their way inside, but the portcullis is impenetrable. The windows are also made of this material. De Grenefeld told me that an skillful acrobat like me could easily climb the exterior of the tower to the top and gain entrance that way. He would pay a nice sum for a rare old book called 'De Vermis Mysteriis,' which he knows is somewhere inside the tower. I could keep all the other goods I find. The most dangerous thing would be the Tower itself: De Grenefeld told me that the tower is old and structurally unsafe, but I shouldn't worry if I'm careful enough to watch my step. The task sounded simple enough and the pay is extremely good so I agreed to De Grenefeld's offer. I need to buy some rope arrows and travel to the Glenham Moor. It is nice to do something legal for a change. LINKs: Use the ingame downloader to get it. WARNING! There are VISIBLE spoilers in this thread. I do not recommend reading any further until you've played the mission.

Pff .. now I have to try and implement this I guess: https://www.reddit.com/r/comfyui/comments/1blhkk6/comfyuitexturesimple/ https://github.com/gokayfem/ComfyUI-Texture-Simple I want to finally get a good save name and save path structure where the material class name can be set to have the output saved in a folder with that material class name. And the material name that will be set to all outputted files like: name_diffuse, name_normal, name_specular, name_height, name_editor ( or however these are called in TDM / however the general syntax for texture files is?). When that all works, I like to simplify the whole UI as far as possible and have toggle buttons for creating and saving the maps, so you can only generate a (diffuse) image till you have something you like.

People who use Blender for object editing sometimes run into a problem with material names. It has a character limit of 63. That's usually fine but some existing TDM materials have names which are longer than that, so it becomes impossible to use them. An FM author can make a copy of the material with a shorter name, but that might be adding unnecesary complexity for people who are just making standalone objects to share. I've been mounting a valiant campain on various Blender forums, and some of their LinkedIn posts, to get them to increase the limit, but to no avail. So it's time to take a different approach. Would it be feasible for TDM to rename long materials? The rendering system would have to intercept and replace calls to the original names, or something like that. I'm not sure if that would be an easy thing to implement or if it would set off a chain of complex events or coding etc. Another possible approach could be a material ID sytem, so in Blender the material name could be WoodPlanks_4ACFB987B, which would correspond to something like TDM\long\path\to\material\WoodPlanks That might even be beneficial for shorter material names, as even they are not user friendly to look at in some interfaces.

I identified the issue in DarkRadiant, which may or may not be similar to the main engine renderer. However, the cause is a couple of different aspects of the code whose function I don't fully understand, so I'm cautious about making a fix. First, although we parse shader layers in order, we then sort them so that bump maps appear before diffusemaps. I don't know the reason for this sorting, but it is obviously intentional: // Sort interaction stages: bumps go first, then diffuses, speculars last std::sort( interactionLayers.begin(), interactionLayers.end(), [](const IShaderLayer::Ptr& a, const IShaderLayer::Ptr& b) { // Use the enum value to sort stages return static_cast<int>(a->getType()) < static_cast<int>(b->getType()); } ); For my red/blue test example, this results in a sequence of material stages like this: OpenGLShader: sorted list: + textures/test/spheres_local + textures/test/square_pyramids_local + textures/test/flatred + textures/test/flatblue Notice at this point, we have completely lost all information about which bump maps go with which diffusemaps. At render time (which is done by the light class, since like the engine we now render light-by-light so that shadows etc will work), we iterate over the sorted list of stages and try to assemble them into D/B/S triplets. switch (interactionStage.stage->getType()) { case IShaderLayer::BUMP: if (draw.hasBump()) { draw.submit(objects); // submit pending draws when changing bump maps } draw.setBump(&interactionStage); break; case IShaderLayer::DIFFUSE: if (draw.hasDiffuse()) { draw.submit(objects); // submit pending draws when changing diffuse maps } draw.setDiffuse(&interactionStage); break; case IShaderLayer::SPECULAR: if (draw.hasSpecular()) { draw.submit(objects); // submit pending draws when changing specular maps } draw.setSpecular(&interactionStage); break; default: throw std::logic_error("Non-interaction stage encountered in interaction pass"); } This logic seems largely correct: look for a stage of each type to build up a triplet, but submit an incomplete triplet if we see the same stage type again. The problem here is that the draw.submit() method does not clear out the material stages, so we see them again on the next iteration, and this includes the default stages which are used for an incomplete triplet (black for diffuse/specular, "flat" for bumpmap). So the triplets we build and submit/render go as follows: See the first bumpmap spheres_local and add it to the empty triplet. See the next bumpmap square_pyramids_local, which triggers a render because we already have a bumpmap in the triplet. RENDER the first bumpmap spheres_local with black diffuse and specular (pointless, it's just a black render). Add the second bumpmap square_pyramids_local to our triplet. See the first diffusemap flatred and try to add it to the triplet, which triggers a render because we already have a diffusemap: the default black diffusemap from step 3! RENDER the second bumpmap square_pyramids_local with black diffuse and specular (another pointless draw call). Add the first diffusemap flatred to our triplet. See the second diffusemap flatblue, which triggers a render because we already have the flatred diffusemap from step 7. RENDER the flatred diffusemap with the existing square_pyramids_local bumpmap (which is the wrong bumpmap for this diffusemap according to the material, because we lost this info with the sorting). Add the second diffusemap flatblue to our triplet. No more layers, so submit the final triplet: flatblue with the square_pyramids_local bumpmap. Aside from being 4 draw calls when we should have only two, this also gives rise to the observed problem: only square_pyamids_local is ever actually seen as a bumpmap. The spheres_local bumpmap is rendered, but we never see it because it was rendered with a black diffusemap. So in order to fix this and get the correct result, I need to change two things: Remove the sorting, and preserve the order of material stages defined in the material file. Make sure each submit() call in the rendering code clears out the triplet and leaves it empty for the next loop iteration. But I don't know if either of these are going to be correct in all situations. The outstanding questions are: What is the motivation for sorting material stages by stage type, bumpmaps before diffusemaps? Can this goal be achieved without discarding information about which bumpmaps are associated with which diffusemaps (and specularmaps)? Is it correct to clear out a D/B/S triplet after submitting it for rendering, or are there situations where we actually want the images from the previous render? For example, are there material situations where we might want to render diffusemap A with bumpmap B, then another render with bumpmap C which re-uses diffusemap A without it being listed again in the material file?

Author Note: This is a brand new mission and a new entry into the accountant series. There are some different than usual puzzles in this FM, so if you find yourself stuck try to think about your pathway forward in a logical manner. And if you're still having troubles then pop by this thread and ask (preferably with spoiler tags). This FM is brand new and serves as the first installment in The Accountant series, a few years back there was a small prologue style mission released however I felt that it did not represent The Accountant series so I decided to go back to the drawing board and do a whole new mission that's larger, has a better level design and has a story that lines up closer to what I plan to do with the accountant series. The mission is medium sized and you can expect between 30-90 minutes to complete it depending on your playstyle. Beta Testers Captain Cleveland Crowind Kingsal PukeyBee Skacky SquadaFroinx Voice Actors AndrosTheOxen Epifire Goldwell Stevenpfortune Yandros Custom assets Airship Ballet Bentraxx Bob Necro Dragofer DrKubiac Epifire Kingsal MalachiAD Sotha Springheel SquadaFroinx Available via in-game downloader File Size: 233 MB - Updated to v 1.1 (01.06.2018)

Detection of player, bodies, ropes, etc. by AI depends a lot on how well-lit the object is. The player case is the most important one. It uses its own system to compute lightgem value, which renders additional views on GPU. Even with many improvements over the years, this approach costs a lot in performance, so it cannot be used for all objects which AIs can see. That's why there is another system for computing light values for the other objects. Since the engine was closed source when TDM was originally created, this system is very approximate. It takes into account light intensity and size, but mostly ignores the other factors like shadows, light projection/falloff textures, light texture transforms, blinking lights, lights with some material stages disabled etc. A new light estimate system has been implemented, and it is going to be default in 2.13. In fact, it has already been default since dev17104-10844. As far as I know, it accurately takes into account all the properties that our lights have. It has its own issues of course. It relies on a few samples on the object surface, and it is rather performance-intensive because it casts shadow rays all other the world. I had to distribute its work over several frames to reduce performance cost, so now it takes some delay to compute the proper value (which can also cause problems sometimes). Here is how it works on a test map: What it means for us? On the good side, you should no longer have a problem when you put a corpse into a dark spot under a table but guards still detect it easily as if the table did not exist. On the bad side, the new light values are inherently different, so guards might detect objects in situations where they did not detect them before or vice versa. Also the delay can probably cause some issues e.g. guards acting upon an obsolete value which is updated just afterwards. The effort is tracked in 6546. There are several cvars about this: g_lightQuotientAlgo: value = 0 uses the old system, value = 1 uses the new system. g_showLIghtQuotient: enables debug visualization like in the video above. g_les*: lots of internal parameters to tweak the system (you should not mess with them).

DarkRadiant 3.1.0 is ready for download. What's new: The Texture Tool got its Free Scale operator now, allowing you to fit the texture with the mouse instead of having to type in the percentages. A lot of work went into the Declaration handling (EntityDef, Skins, Materials, Particles, etc.), which is now much more robust and more conformant to how the game is doing things (at least until TDM 2.10). The Material Editor got a plethora of issues resolved Improved the Model Export dialog and options For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.1.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 3.0.0 Feature: DR doesn't consider wildcards in skins Feature: Reload Images eature: Texture Tool free scale Feature: Add "Show Definition" to all ResourceTreeView instances Fixed: "Reload Defs" doesn't remove entities that have been commented out Fixed: 'Reload Sounds' doesn't load new FM sound shader definitions Fixed: Reload Defs is not sufficient for reloading modelDefs Fixed: Models are reset to origin after reloadDecls Fixed: Skin Chooser doesn't preselect non-matching skins Fixed: Moving speakers deletes distance spawnargs if they're the same as in shader Fixed: Unable to select func_emitter with particle attached Fixed: Particle Editor Preview lacks vertex colours in lighting mode Fixed: Particle effects still visible when hidden via layers or filter Fixed: Entities referring to modelDefs should use the "idle" pose where possible Fixed: DR does not parse materials in def files Fixed: Modifier Hint Popup can crash when hitting Ctrl/Alt/Shift keys during shutdown Fixed: Insignificant digits displayed in Surface Inspector shift/scale/rotate values Improvement: Skin Chooser: show in which .skin file the skin is defined Improvement: Declaration Block Parsing overhauled Improvement: Python Interface for IDeclarationManagerImprovement: leave player start entity selected after placemen Improvement: Let Map Info show materials used by models Improvement: Renaming Declarations causes problems when saving it later Improvement: Light Texture Preview should display editor images if present Improvement: Remove comments about particle generator in .prt files Material Editor: New Material is locked if the default unnamed name is already in use Material Editor: allow to delete materials Material Editor: image browser's "cancel" button rewrites the material source text Material Editor: does not save manual edits to source text Material Editor: should show .mtr the material is defined in Material Editor: after "Reload Images", image previews are only updated when selecting a different material Material Editor: suboptimal preview for cubeMap materials Material Editor: preview object doesn't have smooth shading Material Editor: preview doesn't take "scale" into account in Textured Mode Material Editor: blend add stages are rendered separately in preview in lighting mode Material Editor: test frob highlight button not working Material Editor: doesn't remember settings from previous session Material Editor: image thumbnails use "scale" keyword from previously selected material Material Editor: frob highlight stage not updated correctly when changing diffusemap Material Editor: using Escape to close ignores unsaved changes Material Editor: Global Settings should be preselected Material Editor: some declaration text is lost while editing#6047: Material Editor: clicking "cancel" when selecting a light classname clears the classname field Material Editor: new materials always sorted last Material Editor: filter for image browser Material Editor: can't unlock editing on materials in "Other Materials" folder Material Editor: tries to save materials in DarkRadiant folder if no FM is installed Material Editor: allow to change preview backgroun Material Editor: preview renders shadows for noshadows materials 'Export selected as Collision Model' doesn't auto-create path folder and throws error Model exporter: manually enter export origin Model exporter: export origin choice should use a radio button Model exporter: only 1 entity's model is reloaded Model exporter: "Use entity origin as export origin" still uses map origin Model exporter: rename "Center Objects around Origin" The list of changes can be found on the our bugtracker changelog. Have fun mapping!

When I open the Material Editor in DR , I get the following error and DR freezes: It's frozen, so I can't click yes or no. This sometimes happens, usually it just crashes to desktop (possibly giving the same error, but it's too fast to see).

Even if you are going for a very shiny material, I don't think it's a good idea to overwrite the existing material. At the very least, a new material should be made, allowing mappers to choose if they want to use the legacy version or this one

Here's the pre-release build 3.1.0pre2 After this pre-release phase I'm going to consider doing this differently, like pushing out the releases more regularly, skipping the "beta" phase. It's a lot of work putting the pre-releases together, and I'm somewhat tired of it. What's new: The Texture Tool got its Free Scale operator now, allowing you to fit the texture with the mouse instead of having to type in the percentages. A lot of work went into the Declaration handling (EntityDef, Skins, Materials, Particles, etc.), which is now much more robust and more conformant to how the game is doing things (at least until TDM 2.10). The Material Editor got a plethora of issues resolved Improved the Model Export dialog and options For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/12zKwbeesRIMP7DNeGd0znGl5xqBVrrPX/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/12u5YtpDvpIPL7cR8EPdIIFcnjx9TzpCe/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 3.0.0 can be seen on the Bugtracker changelog, here's the summary: #6065: Feature: DR doesn't consider wildcards in skins #5503: Feature: Reload Images #5805: Feature: Texture Tool free scale #6021: Feature: Add "Show Definition" to all ResourceTreeView instances #6003: Fixed: "Reload Defs" doesn't remove entities that have been commented out #6007: Fixed: 'Reload Sounds' doesn't load new FM sound shader definitions #5504: Fixed: Reload Defs is not sufficient for reloading modelDefs #6035: Fixed: Models are reset to origin after reloadDecls #6064: Fixed: Skin Chooser doesn't preselect non-matching skins #6062: Fixed: Moving speakers deletes distance spawnargs if they're the same as in shader #5988: Fixed: Unable to select func_emitter with particle attached #6000: Fixed: Particle Editor Preview lacks vertex colours in lighting mode #6061: Fixed: Particle effects still visible when hidden via layers or filter #6036: Fixed: Entities referring to modelDefs should use the "idle" pose where possible #4910: Fixed: DR does not parse materials in def files #5982: Fixed: Modifier Hint Popup can crash when hitting Ctrl/Alt/Shift keys during shutdown #5981: Fixed: Insignificant digits displayed in Surface Inspector shift/scale/rotate values #5727: Improvement: Skin Chooser: show in which .skin file the skin is defined #5977: Improvement: Declaration Block Parsing overhauled #6023: Improvement: Python Interface for IDeclarationManager #5972: Improvement: leave player start entity selected after placemen #6066: Improvement: Let Map Info show materials used by models #6073: Improvement: Renaming Declarations causes problems when saving it later #6057: Improvement: Light Texture Preview should display editor images if present #6002: Improvement: Remove comments about particle generator in .prt files #6071: Material Editor: New Material is locked if the default unnamed name is already in use #6031: Material Editor: allow to delete materials #6054: Material Editor: image browser's "cancel" button rewrites the material source text #6030: Material Editor: does not save manual edits to source text #6055: Material Editor: should show .mtr the material is defined in #6069: Material Editor: after "Reload Images", image previews are only updated when selecting a different material #6050: Material Editor: suboptimal preview for cubeMap materials #6042: Material Editor: preview object doesn't have smooth shading #6043: Material Editor: preview doesn't take "scale" into account in Textured Mode #6053: Material Editor: blend add stages are rendered separately in preview in lighting mode #6059: Material Editor: test frob highlight button not working #6045: Material Editor: doesn't remember settings from previous session #6046: Material Editor: image thumbnails use "scale" keyword from previously selected material #6056: Material Editor: frob highlight stage not updated correctly when changing diffusemap #6049: Material Editor: using Escape to close ignores unsaved changes #6051: Material Editor: Global Settings should be preselected #6052: Material Editor: some declaration text is lost while editing#6047: Material Editor: clicking "cancel" when selecting a light classname clears the classname field #6034: Material Editor: new materials always sorted last #6033: Material Editor: filter for image browser #6037: Material Editor: can't unlock editing on materials in "Other Materials" folder #6029: Material Editor: tries to save materials in DarkRadiant folder if no FM is installed #6048: Material Editor: allow to change preview backgroun #6040: Material Editor: preview renders shadows for noshadows materials Changes since 3.1.0pre1 #5997: 'Export selected as Collision Model' doesn't auto-create path folder and throws error #6013: Model exporter: manually enter export origin #6012: Model exporter: export origin choice should use a radio button #6014: Model exporter: only 1 entity's model is reloaded #6011: Model exporter: "Use entity origin as export origin" still uses map origin #6015: Model exporter: rename "Center Objects around Origin" Thanks for testing, as always!

I had an interesting idea in regard to how the TDM engine handles Z-fighting. It comes after my last FM where people reported terrain patches that were too flat causing visible Z-fighting with the ground brush: It seemed weird as both surfaces had the same shader and their mapping lined up, therefore even if the surfaces overlapped the same pixels should have been fighting with no visible artifacts. Turns out the engine makes it so even if the material and its relative mapping is identical, the surface also becomes brighter whenever there's overlapping. I was wondering if unless we're stopped by deep limitations in OpenGL, there is at least a way to get rid of this brightening effect. If we have the ability to control how Z-fighting is handled, I had an idea which could turn it into a great feature available in other engines: My suggestion is to mix the colors on all material maps, so instead of randomly adding them together we settle for the average of all Z-fighting surfaces per pixel. The reason this would implement an useful feature is if we could do it per map, we'd have support for mixing the albedo + normal + specular maps on multiple surfaces in realtime, something not currently possible unless done by the texture or material. Imagine a graffiti drawing on the wall: We could deliberately have the decal perfectly overlap the surface of the brush instead of having it suspended a bit in front... doing so would cause both the albedo / specular / normal maps to be combined, lighting would then follow the bump map of both the brick as well as the decal so both produce depth on top of each other on what would still appear to be a single surface. Even if my particular idea isn't possible, it would be nice if we could at least get rid of the brightening; Z-fighting would still occur, but at least it wouldn't be as obvious if you don't look closely.

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one 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! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

It looks like super polished metal armor, taken out of the closet once a year to use in a tournament or battle reconstruction event. Very sterile look. I imagine that something a guard wears to work everyday would look much more dull and dirty. Dark Souls & Elden Ring armors are an awesome reference, the material work in particular.

@nbohr1more, I just recently noticed that back in Oct you reported in https://www.ttlg.com/forums/showthread.php?t=152771 I didn't see anything about this in the current "What's New in 2.13". Will this new functionality actually happen for 2.13, and if so what FMs can now be re-downloaded to get the enhanced translation packs? Particularly "early TDM missions [that] also have German, Italian, French, etc translations". Pointer to any new bugtracker/forum/wiki info about this appreciated.

I think it's good to make sure it's only happening in 2.13 and not also in 2.12. If it also happens in 2.12 it's probably just an (lod related) mission bug that the missionmaker (bikerdude) has to fix. I already send your post info to him (he's not on the forums)

Ah, the material def probably needs to be set to forcehighquality. I wonder of the diffusemap is DDS ?

Well if you can figure out how to make the material code work you can change the flickering on a per light basis via that parm4 spawnarg. I think it can be useful. I personally find it a bit complicated to wrap my head around though.

While I agree with you, there's no getting round the fact that the licence itself specifically lists DEF files (and likewise all sound/material shaders etc. since they're also non-software components) as being under the artistic licence: So, only DEF files that were worked on by specific people, who can still be contacted (since aside from out of date contact information, Grayman worked on some of them) to gain permission could either be used in full or information used from them based on the above.

Happy 15th Anniversary to The Dark Mod! As of October 17th. 2024, 15 years have passed since the TDM 1.0 release! In that time, we evolved to most or all of the features that players were asking for since the concept of TDM was first mooted in the TTLG forums in late 2004. Campaign Support, Soft Shadows, EFX Reverb, Multi-Core Rendering, Uncapped FPS, Ambient Occlusion, Subtitles, are among the roster of perennial requested things that have been brought to life by the development team in addition to the core Thief 1 \ 2 game-play items like the Lightgem, Rope Arrows, Swim-able water, lock-picking and ( of course ) advanced AI enemies. To commemorate this occasion, please join us in celebrating the Release of 5 missions for our 15th Anniversary Contest! . The Imperial Sword Bikerdude was encouraged to reclaim an abandoned version of his older mission and rework it into a new one. Now the formerly lost work is a glorious new experience with scripted dialog, special events, and a decayed imperial cityscape! . The Wizard’s Treasure Thebigh has made yet another bite-sized mission with a focus on quality game-play and challenge. The mission is extra impressive for the scope and visuals achieved since his decision to join the contest was fairly late compared to other entrants. . You Only Fly Thrice DeTeEff has continued his progression of high quality and complex releases. Another relative late comer to the contest, this mission is a tour-de-force of excellent game-play ideas and is quite handsome with excellent volumetric lighting and modular asset usage. . Volta 3: Gemcutter Kingsal has decided to release his long awaited Volta Series sequel to be included in the contest. DO NOT MISS THIS MISSION! . Pinnacle: A Test of Talents UncertainTitle and TwilitWitch decided to risk their first mission release to be included in the contest roster. The use of both modular assets and many custom models give this mission a familiar yet refreshing visual appeal. . Please join the celebration and vote in the forum threads for each respective mission based on their contest criteria ( Game-play, Story, Visuals ). . . The Dark Mod 2.13 “Developer Build” The Dark Mod 2.13 is still a few months away from release but we wanted to highlight the fact that a few more of the long requested changes have been added in the upcoming release! . Parallax Occlusion Mapping! In the above video, you can see a that TDM has finally incorporated the long requested effect. This wont be applied to all textures since there may be some problems with visual anomalies and performance but we are already preparing for a future where lots of textures use this new and more three dimensional surface effect. Better AI sight! While the AI have always been good at seeing the player due to the lightgem ( sometimes “too good” so we had to nerf their sight ), AI have had various challenges seeing things like bodies, missing objects, opened doors, weapons, blood, etc. This is because it is not practical to give all entities \ objects their own lightgem. Instead we have used very simple math to represent lights which don’t match shadow and light textures. In 2.13 a new sampling approach aims to improve this so that AI can better see ( or not see ) items and bodies in a way that better matches the actual lighting in the mission. Mission Search! There is now a search window where you can specify the mission author or title to help you find your preferred mission rather than scrolling through over 170 missions. You can also change how mission titles are rendered with either the original title or the title with prefix words like “A, The” moved to the end. Improved Training Mission! The Training Mission has been upgraded to include a Vine Arrow tutorial, a Slow Match tutorial, EFX Reverb, Volumetric Lights, and some performance optimizations! Translation Packs! Between TDM 1.06 and 2.0 Tels and the translating community started translating many missions but these translations required that the original mission be altered in a way that made it harder for the mission authors to revise. The meant that translation packs were in limbo being hosted by 3rd party sites \ forums along with their orphaned old missions. The translators over at the Darkfate forums came up with an solution by including not only the translation strings in the translation pack but also the altered map files, GUI defs, etc that had translation work done to them. This would leave the original mission untouched but allow translation packs to override some parts. We have gone through the old archive of these translations and have reworked them to work with the latest version of TDM (and the associated missions). Most of the translations are Russian ( due to the continued work of the Darkfate people ) but many of the early TDM missions also have German, Italian, French, etc translations too. Subtitles! Datiswous has been creating story subtitles for many of the existing missions in the TDM mission database. Most authors have incorporated these into their official releases, otherwise players can still add them to the FM folder. . Hidden Hands: Blood and Metal Campaign Just before the 15th anniversary entries were starting to arrive, JackFarmer released an enormous 5 mission campaign that continues his well regarded “Hidden Hands” series!

Thanx, in the Texture guidlines I read normalmaps should be TGA (uncompressed, no RLE) and I can't find any "node" for comfyUI that can save to TGA .. but I have a node that can save to DDS (bc1, bc3 or bc5) with mipmaps. Thing is that this node also creates a json with it. There is an other node that saves in DDS that it has no settings but doesn't create an other file with it. If this node puts out bc5/dxt5 with mipmapping, would it be acceptable to save diffuse, normal, specular and height with it? The other thing is, since it can't save in TGA, what fileformat would be preferable for the highres backups? I'm now making a automated save structure for the different maps where project name, material type, optional sub type and material name can be set globally and it will save in projectname/(dds)/textures/materialtype/(subtype)/materialname The materialname wil be assigned the appropriate postfix; _local,_s,_h,_ed. I think the folder HighRes will be in in projectname/textures/materialtype/(subtype)/HighRes. Or would there be a better directory for that? The maps will be downsized to the apropriate max resolution before saving, but ofc. the high(er) resolution images won't be downsized. It's quite a puzzel, but it should all work in the end : )

These days a height map is relatively straightforward to derive from a normal map using pretty much any node based material software (there is usually a dedicated node for this). Provided the result is even physically correct, in my limited experience this will not necessarily be suitable to use as a displacement map in the game right away. There will be a lot of high frequency detail which give a noisy result (this kind of detail in a texture remains better handled by the normal map) and the black/white values will need to be adjusted to get both a good displacement effect in the game AND retain any practical versatility in the texture itself (for all the reasons I outlined above). The greater a proportion of the displacement map you get to approaching a value of 1 (white) while still keep the effect you want the better result you will get when you try to go and use the texture in a map. This is obviously very early, and I am just a amateur so consider this advice as opposed to firm guidance. If I am dealing with an existing heightmap I will usually: Level adjust to remove detail and bring the values closer to 1 Apply blur and reduce resolution to further remove detail Prep a corner wrapped material test and begin to adjust the min/max values in the material def and/or steps 1 & 2 in until you get *acceptable* tiling across the transition - this will *not* be perfect - you just want to minimize and to minimize distortion or being able to see *past* the edge via the parallax. This looks like a pretty great example of what you want in a displacement map in terms of the frequency of detail!