Search the Community

Type of mission: Mansion/Estate/Horror Story: Lord Blackgrove recently purchased a rare expensive artifact. The whole family has now disappeared leaving the manor empty. Time to check out the manor and see if the artifact can be found. Build time: My first map ever, 300 hours (5 months). Credits: Kingsal - Breaker script for light switches and elevator Dragofer - Ambience Track 'Intent' Springheel and Sotha - Video Tutorials (those videos really helped) Feedback and testing: Cambridge Spy, Dragofer, nbohr1more, Acolytesix, wesp5, Shadow, Zerg Rush, AluminumHaste, prjames The whole community. Download (1.03): https://drive.google.com/file/d/1wZc_nqHoX7kQvzfg08EpoRy2hyuH7mw3/view?usp=sharing Edit: Version 1.02 provides large performance improvements in the outdoor areas. Be sure to set TDM Object Details (LOD) to Normal (or lower) to take advantage of some of the optimizations. Edit: Version 1.03 further improves performance around hedges thanks to HMart's alternative hedge model. I’ve had a mission like this in mind for years. My main influences and inspirations are: Deus Ex - Chateau DuClare (https://youtu.be/9QLT_l8aH78) Clive Barker’s Undying - Main Mansion (https://youtu.be/t8PyXhCQB3Q?t=90) Thief Deadly Shadows - Shalebridge Cradle (Almost everyone should be very familiar with this one) (https://youtu.be/Rw4YZuRUgXA) In case anyone gets stuck and needs help, I’ve listed some questions and answers below that will hopefully help. FAQ

There's a lighting issue in "William Steele 1: In the North" at -1153.92 3523.22 -955.75 29.8 -145.6 0.0 There's a candle on the other side of the wall. In 2.12 dev, that candle's light leaks through the wall at the base of the door as seen in the video, comparing 2.11 and 2.12-r10451.

I think there is no problem with noshadows parallel lights: they are well-defined in the current engine. It can be used as local light to brighten the window, as @HMart does. I hope there is no reason to have shadows in this case? The parallel and parallelSky are almost the same thing, except that parallelSky traces light beams from areas containing portalsky world surfaces, while parallel traces light beams from the area where light origin is located, which is never what you need for a global parallel light (like moonlight). There are many missions where this issue is hacked around, and all of them result in issues like double lighting if door is open, or lack of lighting in some outdoors areas. And there is no way to fix the engine to make these missions work properly --- the maps themselves are wrong. If you want to do a global parallel light, the parallelSky is surely what you want to have, and parallel is most likely not. But note that to make parallelSky work you also need to follow some rules. The issue with local parallel light is that objects outside light volume can cast shadow over objects inside light volume. This is pretty weird by itself: you move object closer to light volume, and at some point its shadow instantly turns on. The engine determines whether object intersects light volume approximately (using bounding boxes and such stuff), so whether you get shadow from an object close to light volume or not is implementation-defined. Today you have no shadow and it looks nice, tomorrow culling is changed and the scene gets unexpected shadow. So the bottom line is: Global parallel lights should use parallelSky and follow some rules. Local parallel lights should be noshadows. All the rest is not well-defined: you'll avoid a lot of trouble by avoiding it altogether.

The light coming from the windows was actually added in the very last update before release. Originally, only the windows facing the moon were lit up and projected moonbeams, but Dragofer remarked that following purely realistic lighting practices often results in an under-lit mission. Although I also find it a bit strange that such stark moonbeams are coming in from all the windows, I think the lighting of the pre-escape sequence is all the better for it. Thanks for playing my FM, Hightide, I'm glad you enjoyed it!

So, I just retextured the caulk brushes to shadowcaulk and this seems to be working fine. Suitable fix??? However, I did find another light leak right next to this one:

DarkRadiant does not care about engines at all, it only cares about file formats. Whether you can use DR with your Godot-based game will therefore depend on whether your game's assets are arranged in the same way as TDM. More specifically: Your game will need to read map data from the Doom 3 .map format. If it does not, there will be no way to save your map from DarkRadiant in a form that your game can access. Export to OBJ is available but if all you want to do is produce OBJ models then DarkRadiant isn't the right tool for the job (you should use a proper 3D modelling app like Blender/Max/Maya/LightWave etc). Your game assets will need a tree of .def files defining important entities to be placed in your map, including certain "fixed" entity types which are used directly by DarkRadiant itself. There will need to be a light entity defining light volumes, a func_static entity defining a static model, an info_player_start entity to define the starting position, a speaker entity to define sound sources, and probably several others. If these entity types are not defined, then built-in features like "Create light" and "Place player start here" will not work correctly. Your game will need a tree of .mtr files defining material shaders, referring to image paths which will be resolved to either uncompressed .tga files in a textures/ hierarchy, or compressed DDS files in a dds/ hierarchy. If these material shaders are not defined, no materials will appear in DarkRadiant. DR does not make any attempt to load "raw" image file hierarchies which are not referred to by material shaders. Your game will need to define a hierarchy of 3D models in ASE or LWO format. No other formats will show up in the model selector. These models can be stored directly on disk (there is no "model shader" tree required like with materials).

this was a nice little mission, though just long and twisty enough to create a sense of dread! next Dark Mod update needs I fully expected the bottles to become important later, and they did. The layout was a bit tubular, especially coming back - having some new pathways open up and others close at the big trigger would have been interesting. I didn't try to get onto that first balcony because I figured I would reach it later. Well, I did but I did find it a little strange that the moon was low on one side of the house, but there was such strong light coming in windows from both sides even on the lower floor. It added atmosphere, but I kept wondering where it was coming from (since the surround area has been built up, and probably overshadows the house).

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.

Regarding worldspawn "forceAllShadowsBehindOpaque" set to "1", it doesn't seem to get restored on game load. To reproduce (works with any fixed mission using "forceAllShadowsBehindOpaque"): Add "forceAllShadowsBehindOpaque" "1" to the worldspawn in the map file. From main menu, "Start this Mission" or "Restart Mission". setviewpos Notice that the light leak is fixed (not present). Save game. Load game. Notice that the light leak is present (not fixed). Example 1. From main menu, "Start this Mission" or "Restart Mission". 2. Run setviewpos. 3. Save game. 4. Load game.

Thief's Den 3: Heart of Lone Salvation 1736.48 3691.68 -137.75 -5.4 101.1 0.0 Light leak: No light leak:

Normally the aiSee property is set on the light entity, and in this case the property has been set on the light's material. The property sets whether the light makes things more visible to AIs, so its not meaningful to set this property on model materials. If you want to stop AIs from reacting to an object you need to disable its visual stim, and if you want AIs to be able to see through it you need to give it a material that doesn't contain visual clip. Id say we can be grateful someone had the foresight to implement this as a material keyword, too, in cases like this one where you probably can't set spawnargs.

Oh yes: I have both sight and hearing set to Forgiving. I didn't think that would be related: IIRC it only affects the multiplier for how much being seen in light or heard while making noise increases the alert level per event. I should test on a higher alert level too just in case: I tend to be sloppy and impatient thus I used that for years so I wouldn't get caught all the time on more difficult FM's (lots of guards in tight areas with lights you can't turn off). I have noticed an aspect that does work well: If you're making noise by running even in darkness, alert AI will head toward your direction while searching, they won't go around randomly but actually care where the impulse came from. The problem is that this doesn't seem to scale over larger distances: If they briefly see you in broad light at a distance enough to draw weapons, AI won't head toward your general direction but begin searching their own vicinity... and at least on Forgiving the same happens if you shoot a broadhead arrow at a guard's helmet: I still think the guard should actively run toward your location instead, not exactly where you are but they should go to that road or barge into the same building.

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:

I'm afraid the light leaks persist even in dev16854-10518 with a change I understand should fix them on old maps. Just replaying Chronicles of Skulduggery 3: Sacricide and found an area where they're even worse and a light in another room shines straight through the wall. A view from the back of the light shining through: Even from this angle you can see it light up the room through the door.

Thanks. Linux user and I play TDM at least weekly: Never noticed any physics issues myself, whatever happened in the FM must be a relatively rare scenario... that's a FM I haven't revisited so I was lucky to miss the bug then. There is in fact a little problem in latest Beta, though it's so small I didn't bother to document it carefully, but I'll share the idea of it at least: If you climb into a tight space between an object and the ceiling and turn on the flashlight, jumping may cause the light to phase through the floor and disappear temporarily. Say you have a crate pressed against a ceiling where you can only climp and go in while crouched... if the surface is high enough to allow a jump but just low to force you to be crouched, you'll see the light source of the lantern disappear temporarily in mid air. Think I saw it in The King Of Diamonds, if it's important I'll boot it up again and noclip to get a viewpos. Just to make sure you've seen my mention: Please check my message a few posts above where I attached a log, we have a crash where killing AI with a broadhead arrow can cause the engine to go down with a "tried to free uncached trace model" error... not even a main menu crash but one to the OS. It's pretty rare but if you fatally shoot AI often enough it will occur eventually.

I think only in your last mission it could be useful though. In Plain Sight doesn't have a map I think. It's interesting, I might give it a try. It's not actually so hard it seems. You just have to create a layer for every location that you paint over the map, making it semi-transparant in a specific color (in fm A House Of Locked Secrets it's light-blue), or maybe that isn't need, because it could be specified in the gui file I think. Then you have to export all layers as seperate files. Krita has an export command for this and Paintdotnet a plugin. Then you have to specify all the files with the correct (info-)locations in a gui file. I wonder if this could be scripted.. Edit: So it's not very difficult, but just a lot of work.

Apologies, this is where I went wrong. It happened to be a volumetric light shadow I was looking at

why not go al the way up and give the ambient light a screen space reflection term, so the fresnel affected pixels would reflect what is behind them (at grazing angles) instead of a static term? this means that if what is behind them is way darker then the fresnel won't reflect anything, and if what is behind is is way lighter then the fresenel would take a portion of that reflected light, i guess you could use the specularity term of every texture to derive how much those fresnel effects do gather from the SSR term.

Was playing the first FM that makes use of X-ray glasses... seeing them in action inspired me to write about an addition to their idea. This is likely a feature suggestion, I've played most FM's and never saw it done nor found any script / material features that would allow this result, but presume it's possible with a tweak in materials or the renderer. I'm thinking of ultraviolet lamps that can uncover hidden decals or items: The object is invisible if not lit by a specific lamp, only when the light of an UV source touches them they start to show up. A blue-light can be offered to the player as an inventory item or replacement to the standard lantern, a lantern you can pick up and move only in the world, even come in the form of a candle since why not? The player or the environment must move specific objects and / or light sources to the correct positions to uncover secrets such as codes. Some examples: Next to an UV lantern you find a note hinting there's a secret code in a particular room... you must pick up the lantern carry it to that room then place it on a support, illuminating the number-wheel combination or hint on the secret entrance you must go to. We can even reverse the process and have a static UV lamp on a wall, the player picks up an inventory item and must drop it under the lamp to see what's written on it... we can even have a hidden symbol on an AI which will shine when they walk under that one streetlight. They could also reveal frobable objects which can't be touched unless illuminated... maybe a hidden lock to open a door which becomes available when lit, or a readable note which normally appears blank but can be read or contains additional text if there's an UV lantern next to it. So many fun ideas we could do with this given our usual theme and ideas for secrets! At a technical level, the logical way seems like separating the lightmap of light sources marked with the UV spawnarg, then multiplying with its intensity the alpha channels of all material components marked with the UV material flag. This might mean UV lights have to be rendered to a separate pass which could break some performance optimizations? Would be great if an index was possible instead of one flag, that way different secrets can be revealed by different lamps... even an universal UV lamp / material set would do though.

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.

I've idly wondered if you could have a monster that reverses the light gem. That is, it can see you in darkness better than in the light.

In my mission, there is a script that is supposed to display a message if a player is damaged by an explosion. It didn't work because health stays at 100 even when the light gem shows damage was taken. at the start of script I did this; PlayerHealth = $player1.getHealth(); sys.print("Start health = " + PlayerHealth + "\n"); and it reports 100 (or less if player is damaged already) after the explosion (more) damage is taken per light gem, but this; PlayerHealth = $player1.getHealth(); sys.print("health now = " + PlayerHealth + "\n"); Still shows the value recorded before damage was taken. So how do I test for actual health?