Search the Community

Hey folks. Haven't been around for a while, and I mostly just lurk. I really want to get into modding and mapping, but I haven't taken the step yet. I thought I'd focus on what I'm good at until I get to the stage of actually making my own maps, and that is... music. Here's an ambient piece I made today in Reason 10. Rain sounds added for context. https://soundcloud.com/paralytik/tdm-holy-ambient

Has anyone experienced the following issues and can offer advice?: I'm having a problem where some beta testers have reported that belt-attached keys aren't frobable on some AI. I haven't been able to reproduce it at all, and not everyone has reported it. It might be intermittent as well (i.e. it will work on reload, etc). In a couple of places I have some visportals in outdoor areas (i.e. not simply covering a door or window). If you cross them the ambient light changes slightly. These aren't separate locations with different ambient settings or anything. Not sure what's causing it.

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

By way of introduction, Penny Dreadful is a fan mission series dealing with the exploits and misfortunes of Gerald Foxley, lowlife and common opportunist. To stick with the theme of lurid and disreputable pulp literature, these missions were planned to be nasty, brutish and short, which sort of worked in PD1, was not entirely working in PD2, and went out the window with PD3, which ended up much bigger than I ever expected. The series also allows me to experiment with gameplay ideas which do not completely fit TDM standards: Foxley is slightly worse at stealth than the TDM baseline, and can't pick locks: you will need to find different ways of getting into places. In the first episode, The Grail of Regrets, what started out as a routine case of extortion ended with Gerald in the possession of the eponymous Grail. In the second, All the Way Up, these newfound fortunes proved to be shorter than anticipated, as Messer Montrose, a corrupt nobleman, and his ally, the local Bailiff conspired to rob Foxley of the prize to further their own ends. The Grail is now in the hands of Archibald Flint, a powerful crime boss ruling from a mansion on Fiddler's Hill, an infamous den of thieves. However, to get close to him, Foxley has to remove a few obstacles in the way... Erasing the Trail "Kill a man and take his life; wound him, and restore his pride." -- alleyway proverb. "In a city where every window is an eye and every doorway a whispering mouth, it is hard to keep a secret. When I learned of crime lord Archibald Flint's involvement in robbing me of the Grail of Regrets, I knew I'd have to strike quick, and strike first. But I failed. By the time I got near his place on Fiddler's Hill, every gate to his hilltop mansion was locked, every alley patrolled by thieves eager to kill. Two days later, I watched my tenement go up in smoke and flames. The hunt was on, and it wouldn't be over until they'd have their quarry dead or captured. Flint's main enforcer is a man named Grunt, known to communicate in written orders after his throat was cut in some altercation... a real bloodhound. I will have to deal with him one way or another to get the heat off of my back, and allow me to reach Flint himself... Flint is also looking for my dead body, and I'm planning to have it delivered right to his doorstep. Another underworld figure, Almsmaster Quandt, lives a few streets from Grunt's mansion, and he is said to be my spitting image, an uncanny resemblance. Wonder if Flint will recognise the difference... well, time to find out. Sometimes the only way to deal with a hornet's nest is to kick it over. This night, I am back in the middle of it. I have already run into a pair of sentinels, but I slipped into a small garden and jammed the lock behind me with a bit of wire. Hope they don't raise the whole neighbourhood, or this will be over real quick. Time to get moving." Download links: Mega (200 MB)mission downloader!***Performance warning***: as usual, this mission pushes the limits a bit (although less than PD2). The hardware requirements exceed the TDM baseline, and the loading time is fairly long. Optimalisation should be credited to Bikerdude, while the remaining problems are all mine. High-resolution player map (for printing, etc.): Notes: Erasing the Trail is intended to be an open-ended city exploration mission, where you can approach your objectives from multiple angles, and discover multiple solutions to complete them; some more straightforward, some more obscure.Gerald Foxley is a rank amateur who can't pick locks. You will have to find alternate means to break into places.There is no poll to rate the mission because I do not believe in them. Your comments are welcome in writing, however!You can find my concept art in the PK4 file. These images obviously contain heavy spoilers.This mission series predates, and is thus unrelated to the Penny Dreadful TV series. Special thanks: to our testers, Aluminumhaste, Kingsal, Nbohr1more, Oldjim, Skacky and Premier; gigagooga for several new ambient sounds, and sound conversions (Fabrice Hautecloque from Ishar III, tension loops from Golgo 13: the TV series);Yandros, Bikerdude and Goldchocobo for voice acting;epifire! for custom models;The Canon Texture project for texture work.

How you can help depends a lot on what skills you have. I can Record Video Recording "Let's Play" videos or simple walkthroughs of existing missions and posting them to Youtube is great exposure for the mod (see example .) Be sure to let us know so we can link to them. If you have some editing ability, Video tutorials, where you explain how the mod works, or how to use specific tools, would also be great. Video trailers, showcasing interesting places and features, are also great for publicity. An example is . I can Write Writing reviews for missions are always nice, especially if they include good screenshots. Not only does it give us something to post on other forums, but it makes mappers feel good when their mission gets attention (especially if it's positive). We have a collective thread to post reviews in: http://forums.thedar...s-walkthroughs/ Writing reviews of the mod as a whole, targetted an an audience that doesn't know much about TDM, is also very useful. You could also try offering your services to mappers to create interesting readables, or to proofread for their mission. I can Act and Record Audio We are always on the lookout for good quality audio recordings for vocal sets. If interested, you can pick a few different lines from this script: http://wiki.thedarkm...t:_Average_Jack and send the recordings to Springheel, who then writes a script based on the type of voice you have. I can Translate We could always use translations of our menu/hud into more languages. Also, only a few FMs are aavailable in more than one language, so there is a lot of work there, see the I18N Translator's Guide in the Wiki. I can Model Great! Take a look at the model request thread:http://forums.thedar...-requests-here/ and pick something that interests you. Or just post a, "Hey, anybody want a model?" thread in this forum and I'm sure mappers will get back to you. I can Animate Fantastic. We can always use more good animations. Our current character rigs use a Maya skeleton. PM Springheel for more info. I know C++ Have a look at our coding section in the wiki, pick an issue or feature from the bugtracker of the mod or the leveleditor, download the recent sourcecode release (or better ask for an SVN checkout) and get cracking. Make sure nobody is already working on that specific issue and feel free to ask questions. I can Edit Images We can always use completely new textures and/or improved versions of older textures. How to get started and how to import them into the mod. I can Take Photos Good quality photos of useful textures (medieval-ish building facades, dirt, rocks, wood, etc) are always welcome. The fewer directional shadows and higher resolution, the better. I don't have any skills Even if you can't do any of the above, you can still help out. Talk about TDM in other forums; share your (preferably positive) experiences with other gamers you know. Last, but not least, compliment people when you like their work. Saying "thanks", to a developer or, "I really enjoyed your mission" to a mapper will make their day. -------------------- I'll update this further as more things occur to me.

Assuming you're using the location system to play ambients, it should be possible to change the "ambient" spawnarg on that location's info_location entity. The next time you enter the location it should play the new ambient. There should be a setkeyval entity that you can trigger to change the spawnargs of its targets. If the new sound has to start playing while the player is still in the location then datiswous' override may be the way to go. If you're playing your ambient music from plain old speakers then a different approach will be needed.

I'm gonna chalk those artifacts I'm seeing up to my crappy intel integrated HD gfx chip then. Specular & Rimlight both have been the "never gonna be happy with it all the time" variables for me, b/c when they look decent on one map, they look awkward or non-existent on another. One issue with Specular is when doing it in Ambient.fs, it doesn't occlude when inside buildings or dungeons or what-not. When outside, with the moon in the sky, it's natural to see a specular shine down a building. But, when inside, the shine coming down a wall looks unnatural. So, I try to tweak the specular to not be so gaudy. The problem with tweaking specular is that folks like you and me are hyper-focusing on it while modifying things. So, we have a heightened awareness of it as we look around levels, and tweak it as such. But, regular players that aren't hyper-focused on it may not notice it at all if we tweak it too low. That's one reason why I err'ed on the side of "a bit more specular is better than not enough". No sense in processing the effect if it's hardly noticeable by anyone. But, you say it's very strong... can you post a screen shot of what you're seeing? Maybe your getting a different output than I am on your gfx hardware? I mean, if my gfx is giving me weird artifacts while yours isn't, maybe the specular looks different when processed by both, too? Ambient rimlight is also a pain... when I switched over to using the common.fs style of rimlight to avoid the disco lighting of water (still not sure why it's doing it), the rimlight acts as a whole-level brightening. So, I have to tone it down. But then some levels are super-dark (eg: The Ravine), and the rimlight is non-existent. So, I have to kit-bash in a hack to brighten up rimlight when textures/ambient lighting is super-dark. Then there's levels like Marsh of Rahena that don't seem to use Ambient light for the darkness...d'oh. I also had to apply the 1-NdotL hack to rimlight to keep it from over-brighting ground same way specular was doing. Then there's personal preference... some folks may want more specular / rimlight .. some may want less .. so it's just never going to be one-size-fits-all. And, the real solution would just be to go through all the textures and create real spec maps and such that are missing. I wonder if there's an offline batch process algorithm that can do that? They have data sci algorithms that can batch-process upscaled image resolutions. (Folks that play original Doom did that to the graphics to take the original low-res graphics and artificially high-res them into a texture pack, that way the graphics card wouldn't have to waste processing doing it on-the-fly). Even if there was a batch processor to create spec maps, or convert non-PBR stuff into PBR by creating albedo, roughness, etc maps.. it would still take sifting through the results to make sure it all looks decent. An algorithm might be fine for a majority of things, but may not make some stuff look decent. This guy's using a software program, but I wonder if there's like a python lib to code up a batch process... That's beyond the scope right now, though. LOL I've attached a new version of my modifications with a few more tweaks... v 0.55 ambient rimlight takes darker shadows lighting/color textures into account and brightens up a bit to keep from fading into nothing on super-dark maps (only on maps that actually use Ambient light, like The Ravine... not on maps that ignore Ambient light.. like Marsh of Rahena) like ambient specular, ambient rimlight also dims on ground (1-NdotL) to keep ground from being super-bright and awkward. But, added in a max() to cap the negation, so it doesn't get rid of it all. I started experimenting with ManyLights, but no drastic changes in this version. First experiment was finding out that we can create varying arrays to pass arrays of values between vertex & fragment shaders. So, I thought it'd be smart to pre-calc things for each light in the vertex shader like I did in interaction shaders.. so, "for each light in lights, pre-calc TexLight, Attenuations, etc" and pass arrays of that to fragment shader. Got it going, and it killed performance. LOL! (IE: I was getting like 12 FPS in the archery yard on Training Mission, and suddenly I was getting 2 FPS.. LOL) Memory is the constraint. Too much stuff demanding too much gfx memory to pipe over. So, nixed that idea. I run stencil shadows instead of shadowmaps, b/c of my podunk gfx chip, so lost interest in messing with manylights. glprogs.stages.interaction.055.zip

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

v 0.43 started work on "manylights" shaders Ended up on the performance tweaks TDM wiki page, and it talked about setting "r_shadowMapSinglePass" from 0 (which uses ambient/common) to 2 (which uses manylights if you also have shadow maps enabled instead of stencil shadows). What it does is do all the shadow & lighting in a single pass. (Basically passes in a light array and iterates through it, branching on direct vs. ambient light). It can help with performance if folks have shadow maps turned on (I was getting a few extra FPS with it on). So, I started farting with the manylights shaders to sync them up to look like the ambient/common ones if someone is using r_shadowMapSinglePass 2. Also to see if there's a performance hit from the changes I make. All I've done so far is just shuffle code around w/o really changing manylights outputs. I created a "manylights.funcs.glsl" file to dump bindless routines into, but I also #included the "interaction.funcs.glsl" file in it at the top, so it will import and use shared stuff from that. I chucked more shared code into "interaction.funcs,glsl", like calcNorms() and stuff, which both interaction & manylights shaders share. I just organized code around a bit for the time being, so manylights still pretty much does what it's doing. I bound keys to r_shadowMapSinglePass 0 and r_shadowMapSinglePass 2, so I could easily flip back-n-forth between the two for comparisons. Took some screenshots on Training Mission to compare-contrast. These are animated gifs showing "original" (manylights) vs. "modified" (tweaked ambient/common shaders I farted with)... These are ones I consider "good" (subjective, eye-of-the-beholder, but I like them).. blacksmith ... https://i.imgur.com/P8Jv5Ba.gifv archery yard 1 ... https://i.imgur.com/vYJftj4.gifv archery yard 2 ... https://i.imgur.com/KtwgGrq.gifv Now some "bad" comparison shots... gamma room ... https://i.imgur.com/JTv0sIQ.gifv central hall ... https://i.imgur.com/Eh7ofhf.gifv The problem I'm having is getting the final additive ambient light color to look right in both outdoor and indoor areas. Also, the ambient rimlighting amount in my needs to dynamically adjust or something. In really dark areas, you hardly notice the rimlighting, since it's enhancing the final color. If final color is very dark, it won't bump it up much. Then in areas with more light and lighter textures, the ambient rimlight is super bright. In outdoor areas, it blends in, b/c the full moon is out. But, inside... woof. The gamma room is lit up unnaturally. So, I'll have to figure something out. The main difference in my shaders is just applying more fallback specular and rimlighting to everything. Also, all the light colors are multiplied by the diffuse color, hence the colors are a bit deeper (an effect that can be done by just playing with brightness / contrast.. but I was trying to stick with shader tuts that made it seem like all light colors need to mul by diffuse color.) I don't like how muted the rimlight on the column in the main hall looks, though... I like the brighter one from original shaders. I may experiment with going back to using a toned-down diffuse color for specular instead of full diffuse color to let more white-bright show up. One thing I noticed in manylights (and I think ambient.fs was doing it, too).. there's a specular applied to the light dot which essentially does a rimlight effect by applying highlight to the top parts of bricks on walls and things.. before the ambient part even gets to the rimlight part at the end of it's shader. So, I'm going to dig through and see if I can tweak the tweaked shaders to do more of what the originals were doing. I sort of tore things apart to understand them, and piecing things back together. I just have to experiment with more things to figure out what they're doing. Not sure this is worth working on, b/c if 2.10 comes out, I'll just be back to square one starting over on the shaders again trying to figure out what's still used, what's changed, and what's deprecated, since changes aren't merged in to source. glprogs.stages.interaction.043.zip

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.

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

Holy crap this problem is driving me crazy downloaded whole another copy updated windows updated drivers deleted netframeworks reinstalled them nothing works ! look at this

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?

Now that I think of it, when the HDR-Lite feature was added in 1.03 there was a discussion about how adding all these directional effects would impact generic ambient lighting used for local bounce lights. At the time, the solution was to replace the ambient_world light with texture based brightening and shading while leaving the standard ambients as is. As I recall, in 1.08 (when we first used Doom 3 engine sources) @rebb then replaced the texture based ambient with a dedicated ambient shader for all ambient lights so we probably just extended the fresnel and other effects to all ambient lights. The ambient world was meant to be an "easy button" so that mappers would not need to fuss with lots of ambient lights everywhere so that is why it was given directional attributes so it follows that we should probably restore this dichotomy and make sure that we even consider removing all directional behavior from the ambients except ambient world.

v 0.44 tweaked minimum ambient light color removed diffuse texture from specular misc tweaks This doesn't include vertex files (removed modifications to them, so no point in including them), nor PBR/POM files (disconnected code from them). It does include the manylights fragment and funcs. I messed with minimum ambient light color again after trying to play Crystal Grave and it being almost pitch-black in shadows. The original shaders start with an ambient light dot at 0.5, then add things to it. So, in a sense, they're using 0.5 as the base ambient light amount. I messed around with the "AOcolor" variable to do that, but wasn't happy. The u_minLevel variable didn't seem to get set to force a minimum light value. (Level-dependant? Some level authors maybe want pitch-black shadows?) End result was I added a minimum light value to both ambient light dot & cubic attenuation (which is multiplied into non-cubic attenuation, b/c cubic path isn't processing). This helped boost the min light level. Had to boost cubic attenuation, b/c if not, it darkens everything down. I created a #define MIN_AMBIENT_LIGHT variable to tweak. I tuned it based on Training Mission. ~~~~~~~~~~~~~~~~~ Removed diffuse texture from speculars, b/c they were over-coloring the speculars. EG: some doors in torch light would look hyper-yellow, like they were amplifying the light color. The columns in training mission had a dull shine along the reliefs instead of that nice, crisp shine. The diffuse param rgb & var_Color and such are needed for specular, b/c that's light color. (Lightcolor.rgb is light attenuation, and diffuse.rgb is actually light color.. it's confusing). Without any of that, specular is pure white and looks awkward. But, with diffuse texture mixed into it, it darkens and colors too much, looking odd again. Anyways, I kept the old code where matDiffuse texture worked into specular, and it's commented out now. But, the new code doesn't do that. With diffuse texture out of specular, specular brightened up quite a bit, so tweaked it down. The goal was the have a faint, broad shine in ambient light. Didn't want it sticking out like a sore thumb. I also adjusted the ambient specular to show up on floors again, but very faintly. Rim lighting still uses diffuse texture as a base color to keep it from looking like white haze in shadows. Played through Crystal Grave, and the rimlighting and min ambient light made shadows dark but not "keep your lantern all the time" dark. glprogs.stages.interaction.044.zip

Version 3.0. Not much changed this time: I made a custom material to use a square falloff image, this helps the lamp cover more ground to make the most of the effect. Tried making flame irradiance pulsate but it didn't work, prolly too subtle to matter. Unless a major change comes to mind this should be the last one for now. tdm_irradiance_v3.0.pk4 At the moment this mod is still hit by three major deal breakers: On maps with a lot of portals the cutoff looks hideous and is barely better than letting the light shine through walls. It needs a better way to prevent wall leaks, obviously without using shadows. Performance is too affected on complex maps, I'd say I'm seeing -30 FPS at the very least. For such a simple estimation it's downright silly: We could have a smart algorithm doing real ray bounces at this cost. I'm not happy with overriding the base light classes to attach lights on top of other lights: I'd rather every light on the map gets an irradiance volume tailored to its exact appearance. This would be easy for me to do with a script that runs once scans all lights and attaches customized ambience to them... the next update would likely be that, but I don't know if I should bother unless #1 and #2 are also resolved (and this). Based on my experience making this mod, I have an idea on how we could do this properly with an engine change. @cabalistic@duzenko and other graphics devs I'd like your input here please. It's based on two essential things: An ambient light decreasing with distance is a good enough estimation for irradiance and provides realistic results. As it's directionless and requires no per-pixel effects (specular or normal mapping) this approach can in theory be very cheap too. In my opinion it looks far better than having nothing, would work great until some hypothetical future where we had real ray tracing... as a rule our engine already uses many such good tricks. The shape and radius of the indirect light doesn't need to exceed that of the direct light but should be equal to it. The effect is only visible in and intended for areas covered by the light's radius box, but not touched by its direct light due to shadows or surface direction. Knowing this I had the following thought: Suppose we had a setting to let every light have an ambient component, meaning any standard light material is treated like it has the "ambientLight" flag but without affecting the normal functionality of the direct light. The cvar multiplies the effect of the ambient component, when enabled you'd set it to something like 0.125 (since "_color 0.125 0.125 0.125" gives the best result in my tests). The ambient part uses all light properties normally: Same texture, color, etc... only difference is the brightness being multiplied by the cvar. The advantage of this method is we can get the exact same effect as what I'm doing here but without any extra lights, instead computing the ambiance as part of the same light using existing data to make the calculation as cheap as possible. As the ambient component must remain shadowless to play its role, this doesn't solve the wall leak issue. I have an idea for that but will leave it for later, I don't want to overwhelm with too much at once. I'd like to hear thoughts on this proposal: How easy and cheap would it be to let all direct lights act as ambient lights too for players who want this?

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.