Search the Community

I'm trying to fix the warnings on my end, but remodelling the models is out of my league, so you're going to have to fix the stairs model on your end: "WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/architecture/stairs/set01_stairs.lwo' has 17/8108 nontriangular polygons. Make sure you triplet it down" Edit Also there's this model, which is probably a modelling issue as well: "WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/misc/clipmodels/pickaxe_cm.lwo' has bad or missing uv data" I still have hopes for script-hotfixing the following warnings: "WARNING:Couldn't load image: tdm_tongue [map entity: atdm_ai_townsfolk_female_1] [decl: atdm:ai_head_female02_base_brunette in def/tdm_ai_heads_springheel.def] [decl: female_head02 in def/tdm_ai_heads_springheel.def] [model: models/md5/chars/heads/npcs/female_head02.md5mesh] [decl: tdm_tongue in <implicit file>] [image: tdm_tongue]” (Edit: I hotfixed this issue and attached the hotfix in the tech support forums. The "tdm_tongue" shader should simply be renamed to "tdm_character_tongue".) “WARNING:Couldn't load image: models/darkmod/wood/boards/wood_brown_dull01 [map entity: func_static_53] [decl: old_plaster in skins/tdm_models_architecture_modules.skin] [decl: models/darkmod/wood/boards/wood_brown_dull01 in <implicit file>] [image: models/darkmod/wood/boards/wood_brown_dull01]" (Edit: I hotfixed this issue as well - see the tech support forums - but I think you should still go over this file, because there are a lot of other suspect textures in there as well.)

Yes, this is possible but there are a few things that make it a little impractical. 1) Models do not seal the void so you need BSP brushes behind or inside models to properly seal a map. As I recall, there are doom 3 and quake map exporters that can export your initial block-out geometry as standard brushes so you could do both modeling and brushwork in blender. You’d just have to do it in phases 2) Visportal placement is crucial to performance so you will need to ensure you blender models are cut at portal boundaries so that you can setup brushes and visportals at choke points to prevent rendering outside the player view area 3) model geometry is often too complex for the physics engine. You will need to make invisible clip models or clip brushes that use a more simplified structure to ensure AI pathing and overall collision physics perform well. 4) Models need to be split at light boundaries. If a single light touches a model the engine will do light geometry calculation for the whole model. If enough lights hit a large model it can severely impact performance. Brushes will auto-split on light boundaries but often split in less optimal locations so it has become the convention to use func_static geometry to force brushes to split in the preferred locations 5) blender has no knowledge of specialty brushes like fog volumes, water, SEED auto dispersal etc So it’s possible to do the majority of mapping in blender but ultimately you will need to use Dark Radiant to do the finishing touches The current paradigm is to create modular content in blender and then assemble the modules together in Dark Radiant along with bsp caulking and vidportal placement

Yes, I would guess in creative mode it has tweaked generation parameters, and maybe even an invisible header inserted into the model's memory buffer instructing it to be extra friendly and spontaneous. I think OpenAI's API allows you to modify those sorts of things to some extent. (I haven't tried it yet.) The other thing to keep in mind is that the algorithm doesn't work by thinking of an answer, refining it, and then writing it down. What you see on the page is its actual stream of consciousness in real time. It can only remember and write new text based on what's already on the page.... So its thought process for your discussion might look something like this: The really interesting thing is if at any point you inserted a warning that LLMs are bad at arithmetic and suggested a strategy to work around that limitation, then it might not have made the error or lied about the reason. It always knew this information that would give it the right answers, but until it's written down it's not part of the pattern the model is trying to match so it would be ignored. Bringing this back to games, this demonstrates how immature the technology is. A true consumer AGI based on this technology would be augmented with tools to avoid problems like these: a contextual long term memory that feeds in relevant background information into the model. A supplemental internal memory buffer for planning and contemplation. An adversarial response review process. Etc. We are already seeing developments in that direction, and experiments like the Skyrim NPC demo are showing the way.

PLAYERS * Volumetric lights appeared late before the previous beta, so the quality of volumetrics in 2.10 was rather poor, and the dithering pattern was very annoying to look at. The feature received a lot more development, and now adheres to the standards of modern rendering. The dithering pattern is gone, performance should be much better, and now you won't miss volumetrics even if you prefer to play with stencil shadows all the time! (thread) * Thanks to a certain "AI-heavy" mission, the game code has received major optimizations. It is most noticeable in low performance conditions, when game modelling takes a lot of CPU time. Previously the game could easily descend into the "spiral of death" with FPS falling below 5, now it is way harder due to better scheduling of AI thinking. There is a variety of other game code optimizations which make our lives slightly better. * New version includes several optimizations for shadows, mostly stencil shadows. A long-standing inefficiency of stencil shadows with antialiasing is fixed, new tile-based optimization is added for soft stencil shadows (thread), small lights with large meshes work faster due to BVH efforts (thread). On the side of shadow maps, the rules for distributing the resolution budget are changed: small distant lights no longer steal precious bandwidth for themselves. * There are several improvements on gameplay side as well. The core mechanics of blackjacking enemies has received subtle, yet helpful improvements (thread). Now you can grab many close pieces of loot by holding down the frob button, instead of picking up each item individually. There are several improvements to crouching, making it more responsive (thanks to @Daft Mugi). The in-game downloader now supports "sort by release date" ordering. * There were a ton of small bugfixes for issues like: bow stuck after load, wrong strafe-walk sound, crash when saving shortly after the death of an elemental, melee combat crash, issues with leaning onto doors, missing fracture sounds after loading a save, X-ray glitch in the first frame, toggling solidity/visibility, lightgem on game load, etc. MAPPERS * The engine now supports OBJ model format. This format is much more popular than ASE and LWO. The engine loading code is very lightweight: it will use your model exactly is as, and load it very quickly. The OBJ format is preferred for large meshes due for faster loading times. The only possible downside is somewhat larger download size compared to LWO, although not much and not always (thread). * Renderer should deal with large meshes much faster, thanks to BVH optimizations. Recall that idTech4 was made for very low-poly models. When renderer frontend sees a "surface" in a model, it always treats this surface as an atomic piece, doing all computations for all of its vertices and triangles. This is very good for low-poly models, can heavily drag performance down with large meshes, as several recent missions noticed during beta. The BVH data structure breaks every surface into smaller chunks, allowing renderer to quickly cull away whole chunks. This makes a big difference in case of large meshes (e.g. terrain) lit by many small lights (thread). * You no longer have to write frob-highlight stages in materials, since they are added implicitly. The problem with these stages was that were very easy to forget, which resulted in no highlight on frobable items. Also it increased cognitive load and scared mappers away. While writing frobstages is no longer necessary, the old stages work just fine. So mappers can still customize frob-highlighting if they really want to (thread). * It is now legal to override a single decl of core game in your mission. Recall that "decl" means a material, a skin, an entityDef, a particle, etc. Note that overriding a whole file from core game always worked as expected, but overriding a single decl from a file did not work reliably before (despite the common belief that it should). * The major cleaning of shaders resulted in some changes in lighting model. The aim was to make TDM lighting closer to the standard Phong model, and make it more logical in general. The changes should rarely make a big difference, aside from probably stronger specular (thread). * Added error-reporting to the GUI scripting engine. Implementing GUI scripts is very hard, error-prone, and confusing. Aside from surprising differences in Doom 3 GUI behavior compared to e.g. Javascript in DOM, a lot of confusion was caused by total lack of any error handling whatsoever! In the new version, all possible errors should result in easy-to-understand console warnings, so writing correct GUI is much easier. Also, we fixed a few features, and added a few new ones to the GUI engine (thread). * dmap command received minor improvements. Yet another big rewrite happened for T-junctions fixing code, since it took tremendous amount of time on one mission. Also a few precision improvements were made. * Other small fixes and additions: added script functions getAnimRate / setAnimRate for tweaking animations added script function setObjectiveNotification for silent objective change added script function getCurInvItemCount for interaction with inventory added script variable "AI_ENEMY_TACTILE" to the base AI scriptobject, which is true whenever the AI is in tactile range of an enemy added spawnarg absence_alert_increase for loot items as a proper substitute for absence_alert, giving control over how much an AI gets alerted if that piece goes missing added spawnargs allow_idle_anims / allow_random_headturning for customization during a running mission, useful i.e. for cutscenes AIs notice broken fracture entities trigger_multiple now works on stationary AIs almost doubled tracemodel limits, raising the restrictive limits for making collision meshes for moveable items door movers can now call "used_action_script" whenever something like a key, lockpick or other item is used on them, if they have the spawnarg "call_used_action_script" "1". ASSETS * Many new assets from capable creators in our community have been incorporated into the core assets. These include: Loot assets: Detailed coins and ingots with accompanying lore. Link Ancient loot items suitable for museums, collectors and ancient sites, first seen in the Volta series. A tiling treasure hoard texture for those with unimagineable wealth. 6 detailed book skins including 3 that are lootable, a first for TDM. Link Security assets Highly detailed standing and wall safes - with or without an accompanying combination lock. Link The combination "safe lock" is now part of core assets and can be operated by either scrolling or frobbing. Mappers no longer need to track down this asset and include it with their FM files as a custom asset. Wall-mounted locks in the style of those commonly found in the original Thief games. Camgoyle sentry, a magical stone guardian based on the security camera shooting magical projectiles at the player, first seen in Written in Stone. The prefab also includes a power source pedestal. Link Fully useable audiograph for playing recorded sounds, first seen in the Accountant and Shadow of Northdale missions. A new full-featured scriptobject makes them easy to implement and control via spawnargs. Wiki Furniture assets Posh upholstered armchairs and sofas for the wealthiest nobles. Link A new high-detail grandfather clock with a working scriptobject and a mantle clock. Link A gothic-style cabinet. Link Office assets Including bundled stacks of paper, blueprints, a letter, crumpled paper, waste bins, an end table and an ornate table. Nautical assets Full-scale modular ship prefabs with interiors, allowing anyone to assemble a ship for a nautical mission in a matter of seconds. 1 merchant galleon and 2 smaller sailing ships are available. Link Link Link A large galleon ship wreck in 2 pieces for those sailors who have met an unfortunate end. Decorative assets An impressive multi-tiered wall fountain, first seen in the mansion in Noble Affairs. A new pair of marble lion statues. Link A standing stone menir with carved symbols on it, ideal for pagan missions. Link Stone pedestal with purple cloth for presenting valuable items. Textures High-resolution cobblestone textures for detailing the streets of TDM. Link Starry wallpaper. Lamps A set of 6 bronze vintage lamps has been added for particulary posh establishments. Link Thief-style charge post streetlamp. A new open-top carriage, the barouche. Link Miscellaneous other models, including: wall planter, 7 small "foliage" herbs, 2 mine carts, 6 shop signs, equippable feather duster and 5 decor plates * We fixed all loading warnings on all existing assets. This became possible after creating an automatic map generator which forces the engine to load all assets from every group. All the references to missing files are fixed too, which means a variety of assets have become available: Old noblewoman skin, plain mage robes skin, moor helmet, electrical arcs, stone window decals (5178), yellow banner skin (5563), wine barrel (Link), grass particles (5689), lampion lights and more graffiti decals. PROGRAMMING Under the hood, we updated third-party libraries, and moved to Visual Studio 2022. The "Debug With Inlines" configuration was split into "Debug Editable" (with hot-reload support) and "Debug Fast" (fastest debuggable). Marking the final step in transition to tdm_installer, the old tdm_update program is finally removed, with TDM packaging code extracted to standalone program.

Wasn't sure if I should still post this since the mystery was somewhat solved, but just to confirm this case can be found in the wild with FM's other than mine: Yesterday I played Chronicles of Skulduggery 0: To Catch a Thief. There's a door up on a terrace (I can reinstall it and go there to get a viewpos if anyone's interested) which upon picking and opening will cause the light on the back of the wall indoor to slightly shine on the floor outside through the entire wall. Exact same camera position / angle in both images so you can just overlap the two screenshots to see the difference, though if you look at the bottom left ground it's pretty clear what happens once the door is opened. It's still a bit weird: The wall module model should still be casting a shadow, even if the wall brush uses caulk and not shadow caulk. Whatever the case a few FM's out there seem to have this problem, even if it's not an issue the engine or building modules can resolve I wonder if mappers can be better put on notice about it since like me most are likely not aware this is a thing or what causes it. Looked at the first post again and the video attached to it: Definitely seems like the same thing. Most importantly it wasn't doing this in earlier versions which I didn't realize... I'm seeing the clarification by Stgatilov as well which I initially missed, I definitely prefer the performance optimization but now I do wonder if something can also be done about this eventually.

Author note: It's hard to believe it's already been a year since Act 1 came out! Well during this mission the player will be following Corbin into the Grimwood district to followup on a lead from last night (Act 1) .. the mysterious tablet! This mission is my first time including full EFX support as well as a HD briefing video file, additionally a new script has been added crafted by the talented Obsttorte which has loot flying towards the player when you pick it up. On a level design front I have tried to change things up a bit by really catering towards a number of play styles, this mission can be completely ghosted or you can use the tools at your disposal to wreak havoc on the citizens of Northdale. For the first time I have tried to create more sandbox environments which don't offer clear answers handed directly to you, so if you're having trouble figuring something out try a different method. This mission takes between 1 - 2 hours to finish depending on the difficulty you play on and how thoroughly you explore. I hope you enjoy your night in Northdale! - Goldwell Voice actors Fen Phoenix Goldwell Random_taffer Yandros Beta testers Amadeus Boiler's Hiss Cambridge Spy Chakkman Crowind Epifire Kingsal SquadaFroinx Custom Assets Andreas Rocha DrK Epifire Grayman Kingsal MalachiAD Obsttorte Sotha Springheel SquadaFroinx Purgator With special thanks to Epifire for creating a large collection of custom models, Grayman for helping out with coding, Kingsal for drawing the ingame map and Moonbo for his script revision on the briefing video. Available via in-game downloader MIRROR File Size: 417 mb EDIT: If you are having performance issues please consult this post by Nbohr1more which may address your issue http://forums.thedarkmod.com/topic/19936-fan-mission-shadows-of-northdale-act-ii-by-goldwell-20190320/page-2?do=findComment&comment=436271

Unfortunately many things in this engine are best done on the editor and then called through script, not created directly through script, one of them afaik is triggers. You normally create a trigger by creating a square brush on the editor manually, and give it the trigger_hurt material, so the size and shape comes from that brush, it also creates the physics (a clip model) automatically, then just need to use the script function, entity ent = sys.FindEntity("entity_name"); To get it and use it in the script to do whatever you want. Creating a clip model from script, is probably possible, thou I never did it, so I don't know how... thou I do know how to do it through c++. But I don't think there's any equivalent script functions exposed to the script system, if I'm mistaken please anyone correct me. Perhaps something to recommend in the TDM roadmap?

In this case for a shadow and physics mesh imo is very easy, just make two extra copies of the lowest LOD, slap the shadow material in one and the collision material on the other and make sure both occupy the same space and are on the same item mesh/layer has the main model. In blender (or any other 3D Tool) you don't need to import any TDM material or texture, you just make a basic material for the shadow and collision mesh and make sure to give each the name of the shadow and collision material respectively (not the .mtr file name the full material name, inside the file), is that easy! bear_statue_example.7z ps- here is a fast example of what I said, sorry for not making it plug&play to TDM. I add too mess with the model because I use Modo and it doesn't open ase files, I add to convert to obj using another tool and also rotate it in Modo to be able to work with it, so now is not a, one to one, to the original model and so shouldn't be used with the LOD's that were provided, this because I assume they will not match, but I didn't tested, plus the material name for the main mesh is not the correct, only for the shadow and collision mesh's are correct (follows doom 3 convention). This should be seen just as a model for anyone to know how a shadow and a collision model should be setup. (for those that don't know) I also used the second LOD counting from the last because the lowest LOD seems to not follow the main model silhouette perfectly, it could very well work at the distance but not for a shadow and collision mesh.

I'd like to ask a (hopefully) easier favor from the DR devs on this, considering it's such an issue and making me struggle to keep mapping normally. I know the root issue seems to rely on WxWidgets and may not be solvable on our end, but at least one part of it I consistently run into should be. Like I said I can initially avoid the problem by exporting the "GDK_BACKEND=x11" variable in my shortcut, this makes it go away for the 2D and 3D viewports and only persist in the model viewers which I can care less about. There's just one exception: The moment I press X to use the clipper tool and cut a brush, the 2D view starts experiencing the issue and becomes impossible to drag normally. Because of this I need to avoid using the clipper as much as possible, and whenever I have to in order to get a triangle brush I must restart Radiant immediately after. Would it be possible to figure out what the clipper does that's so unique to triggers this? Does using it reset the 2D views and somehow gets them reloaded by Wayland? If yes could this be avoided so in the meantime it doesn't break that workaround? If at least this can be solved and the GDK_BACKEND workaround keeps otherwise working, it will be a lot easier to wait for the proper full fix. Sorry for the annoyance with this... just want to make some good FM's and using DR this way is running on a handicap that makes the already complex process of mapping even slower.

DarkRadiant is presently suffering from huge slowdowns when editing complex maps. They appear to increase the more models and entities are added to a map: With the building modules used in a lot of places, one of my maps is at the point where DR freezes for over one second whenever I merely toggle a filter which is very annoying for every repeated action. The lag occurs both when moving the 2D or 3D camera or viewport around, as well as enabling or disabling filters or using Control + F to go in and out of editing a group. From what I can tell as an end user, this seems to occur because DR drops models that are no longer being rendered from memory, so whenever a change in the camera or viewport is made everything that pops into view or is recalculated floods back in. While this may be nice to save on RAM, my suggestion would be a change or at least an option to disable this behavior and keep everything precached: Like TDM itself, DR should maintain every model and texture used by the map in memory, only removing it once every last instance has been changed or deleted from the map being edited.

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

I was trying to export a collision model to make a frobbable brush and I clicked 'save selected as collision model'. The 'select model' menu popped up with the last entity I had placed, a crate, highlighted. I x'd out. Now whenever I try to place any entity it's placing a crate with it. 1. how do I un-taff my collision models and 2. how do I actually make a brush into a frobbable object? Meaning, how do I actually export a collision model? Also, I know I have to assign the 'custom grabbable' entity, but do I place that entity and then set something in the spawnargs to refer to the brush I want movable and the collision model? Thanks as always for the help. Coming really close to having a map that is fully playable and getting pretty excited, so it's heartbreaking to get stuck like this in a way that I can't continue for now!

My following suggestion would need changes at the engine level and also require the team to reimport and export the models again from a 3D tool or perhaps make a special plugging for DR to mix the models into a single one, so may never happen but I think it should at lest be considered and it is the following: Some games, include the LOD models, in the main model itself, like how the engine currently uses the collision model and the shadow model, the same could be done for the LOD's, this would have the following benefits that I currently see, it would unclutter the model folder, because you would only need to export one model, all necessary info is within the model file itself, two permit DR to continue with the current model chooser and entity chooser, no need to mix the two or change DR model handling in any big way, apart from perhaps creating a special filter, to hide the LOD surfaces/models if necessary, like is done for the shadow model, and the best benefit imo, instead of the mission maker having to bother with setting up LOD's manually that would be automatically setup by the engine at model import time and so prevent the problem that Dragofer talks about, forgetting or even not bothering with setting up LOD's. How to setup the LOD's in the 3d tool? It could be done like the shadow model is done, using a special LOD material, or if possible they could be put in a different layer that you give a "_LOD_X" name and the engine would read that layer has a individual model, this would need the engine to support importing models with more than one layer, that I don't think it does (but I could be wrong) and I'm not even sure if, ASE and MD5 support extra layers, I know LWO does. My two cents on this discussion.

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

Thanks to Stgatilov for fixing the head model change crash! Though the fix will be featured after next dev snapshot, I'll likely update this mod again once that's out. While few maps have mirrors, remember some may be designed with this mod in mind as the goal is to have it working as both a FM and universal mod. Thanks: I'm glad you like it even if it may not be featured in the mod pack, though I'll likely attempt some of your suggestions at least. I tried to make it intuitive, hence I didn't add special circumstances (like running) for wearing out the disguise even faster so players aren't left wondering what triggers it, however it may be featured next time: I don't remember if there's a way to check if the player is sprinting or crouched, so I'll likely use the player speed thus the faster you're moving the more quickly you're spotted... I might even make it so being seen picking locks or stealing loot instantly makes your disguise fail! Making a helmet no longer usable after being caught once is tricky: Helmets all look the same, therefore guards wouldn't notice if you stole another hat and used that to trick them again... they don't use energy either so needing a special way to recharge them wouldn't make much sense. Remember also that being seen by an alert guard makes the disguise drop faster, and part of the alert level is permanent meaning guards will always catch you a bit more quickly if they were alerted once. The logical solution would be that once you're caught, you can't ever disguise yourself to trick that team again... this would make them too useless and irreversible so no. A good middle ground instead is having a long cooldown timer, so once caught you can't disguise yourself for say 5 minutes. What does everyone think about that?

My compass renders as all white, ensuring I can't use it effectively. Images of the problem and the settings I have: https://i.imgur.com/Z7P6jkk.jpg https://i.imgur.com/TyEwpqE.jpg https://i.imgur.com/c2pMqhb.jpg I'm running TDM no tools due to AMD card. System specs: Computer Information: Manufacturer: Lenovo Model: IdeaCentre K330 Form Factor: Desktop No Touch Input Detected Processor Information: CPU Vendor: GenuineIntel CPU Brand: Intel® Core i7-2600 CPU @ 3.40GHz CPU Family: 0x6 CPU Model: 0x2a CPU Stepping: 0x7 CPU Type: 0x0 Speed: 3392 Mhz 8 logical processors 4 physical processors HyperThreading: Supported FCMOV: Supported SSE2: Supported SSE3: Supported SSSE3: Supported SSE4a: Unsupported SSE41: Supported SSE42: Supported AES: Supported AVX: Supported CMPXCHG16B: Supported LAHF/SAHF: Supported PrefetchW: Unsupported Operating System Version: Windows 7 (64 bit) NTFS: Supported Crypto Provider Codes: Supported 311 0x0 0x0 0x0 Video Card: Driver: AMD Radeon R9 380 Series DirectX Driver Name: aticfx32.dll Driver Version: 25.20.15031.1000 DirectX Driver Version: 25.20.15031.1000 Driver Date: 3 26 2019 OpenGL Version: 4.6 Desktop Color Depth: 32 bits per pixel Monitor Refresh Rate: 59 Hz DirectX Card: AMD Radeon R9 380 Series VendorID: 0x1002 DeviceID: 0x6939 Revision: 0xf1 Number of Monitors: 2 Number of Logical Video Cards: 2 No SLI or Crossfire Detected Primary Display Resolution: 1920 x 1080 Desktop Resolution: 3840 x 1080 Primary Display Size: 26.65" x 15.00" (30.55" diag) 67.7cm x 38.1cm (77.6cm diag) Primary Bus Type Not Detected Primary VRAM Not Detected Supported MSAA Modes: 2x 4x 8x Sound card: Audio device: Headset Earphone (HyperX Virtua Memory: RAM: 8174 Mb Miscellaneous: UI Language: English Media Type: Undetermined Total Hard Disk Space Available: 4972480 Mb Largest Free Hard Disk Block: 726828 Mb OS Install Date: Dec 31 1969 Game Controller: None detected VR Headset: None detected

It's not that no: I didn't modify the properties of the default entity or its flame, in this case it's the standard atdm:lamp_oil_wall_lit entity... also I have player shadows enabled, the player as well as other architecture elements cast shadows fine. Walls are the building modules, eg: model models/darkmod/architecture/modules/interior_set01_corner.lwo with skin diamond_wallpaper as a test. This is the closest to the setup I still have: The origin of the light is well beyond the face of the module surface for shadow casting. Though this shouldn't even matter since the light is in the other room and the caulk brush should itself mark this. I think I noticed this on other maps too while playing, but only now saw it obviously enough to realize there's likely an issue somewhere. I remember seeing the glow of a light from another room shining on the floor / ceiling when it shouldn't, though I didn't document it at the time.

As part of my mission I'd like to have more than a handful gentleman scientists studying and cataloguing specimens discovered on an expedition. A vintage, well-used microscope would be an essential asset. No doubt that this would be a versatile model for many other settings as well. What I'd like most would be a simple, worn-textured model like in the first shot. The other shots show additional or alternative style elements that could be interesting to use.

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?

A few times now I have run into a situation where I have needed an tweaked version of a model, either to remove a chain from a light model or trim or column from a wall model etc. As we now have a few modelers with proper modeling tools in the community it made sense to create this thread instead of struggling away in Darkradiant as I and other mappers have been doing. My first request is for some tweaked version of Springheel's interior wall models that remove the end column/s so we just have a nice flat wall/panel where they meet. And to allow for some flexibility LH/RH and non-column versions of these models would be useful - models/darkmod/architecture/modules/interior_set01_default.lwomodels/darkmod/architecture/modules/interior_set01_corner.lwo My second request is in addition to the removal of the column to also have part of the lower wood panel removed to accommodate a fireplace (models/darkmod/fireplace/fireplace_wooden) so neither are poking through into the firebox. And again LH/RH version would be useful. - models/darkmod/architecture/modules/interior_set01_default.lwomodels/darkmod/architecture/modules/interior_set01_corner.lwo My third request is just to have a hole cut in the center lower wood panel to accommodate a fireplace (models/darkmod/fireplace/fireplace_wooden) so its not poking through into the firebox. models/darkmod/architecture/modules/interior_set01_default.lwo All of the above new models need to be able to snap-able to grid, and line up with the existing models like the current models do. So it may be recommended to keep the origin in the exact same location as the donor model before saving/exporting.

After several months of hard (although very enjoyable) work, I’m proud to announce the release of my first FM - “Cole Hurst 1: Eaton”. Mission description In the northern town of Eaton, Lord Mayor Zelmer is hosting a lavish party at his luxurious estate to celebrate Eaton's establishment... The city's elite, a famous musician and even the Queen will be partaking in tonight's festivities. Screenshots Download “Cole Hurst 1: Eaton” should already be available for download in the game, but you can also grab a copy of version 1.0 from here. To install this copy, simply place the downloaded file named “ch1_eaton.pk4” in your “[the dark mod]/fms/” folder. Notes I would say this FM could primarily be considered a “traditional mansion heist” mission. These were by far my favorite type of Thief 1/2 levels which I have very fond memories of playing through as a child. I suppose this is my humble attempt to create something vaguely similar... I have tried my best to make the story, the readables and the conversations as interesting as I could and so I really do hope that some of you will find it enjoyable. The mission features: I already have some relatively concrete ideas for a follow-on mission in mind, so hopefully I will have time to continue my mapping efforts soon(ish) :) Contributions I have been overwhelmed by the amount of people interested in helping me with this mission. A huge thanks to each and every one of you! Story Kelly Hrupa Voice actors: twhalen2600 (AKA @Benny_the_guard) Kelly Hrupa Testers: @Acolytesix- brisk puzzle solver @duzenko - the man with the admin tools @JackFarmer - objective wrangler @Shadow - a certified spider-monkey who refuse to stay caged @Cambridge Spy - an eagle-eyed book-worm @wesp5 - eager candle-snuffer @madtaffer – readability advisor @prjames - spider assassin @suzy8track – book magician @datiswous – destroyer of crates I would also like to say a special thanks to @Dragofer who has been very helpful with debugging and general advice in cases where I had absolutely no idea what to do. @duzenko has also been very responsive to any game-related bugs that I’ve encountered during the beta phase and also thanks to @nbohr1more for handling this release for me. As I am completely new to mapping in general, I also found @Springheel‘s wonderful TDM New Mappers Workshop extremely helpful when I was first getting started, so thank you very much for creating it. Known bugs/issues While this mission has spent quite some time in beta testing, I’m sure that some of you will discover shortcomings that my wonderful beta testers and I have overlooked. In that case, please do get in touch and I will make sure to address it (to the best of my abilities) in a future update. There are unfortunately also a few (primarily cosmetic) things that I have been unable to solve – at least for this release: The small church model used in Gatwick square has low-resolution textures applied Some picture frames do not match the original frame after being stolen Strange looking shadows on the greenhouses in the garden Visible vertical lines on some interior walls Various gaps/holes in some of the models that I have chosen to use The female mansion lobby guard occasionally sound like a dude

@Nbohr1more has pointed out a strange visual glitch with the hanging light model: models/darkmod/lights/extinguishable/cagelamp_hanging.lwo It's casting unwanted shadows when in the shadow maps mode. It has two surfaces: main surface with material tdm_streetlamp_metal which is noshadows - this one is OKbottom of the holder with material tdm_coals_hot - this one is supposed to cast shadows but for some reason it's not casting shadows in stencil mode - it looks as if the surface is deemed back-facing by stencil code even though it's clearly front-facing to the light view.I would appreciate anyone shedding some light on why the bottom surface is getting culled with stencil - is it a renderer bug or am I missing something? Maybe something's special about the model itself? The map in question is NHAT (anoot.map)