Search the Community

I've just raised this: https://bugs.thedarkmod.com/view.php?id=6334 If you have lights randomly extinguishing on map start and you can't figure out why, it might be because the light is surrounded by a merged water entity and the engine thinks it's submerged. There are links to test maps I've made available in the bug report. Screenshot below illustrates the issue. The arrow is pointing to the water line, and the circled torches are below the water line. The walls are made of glass so it's easier to see what's going on. If you run into this, the workaround is to simply not merge your water entities!

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

Myself and Baal have extensively used BounceLights in our WIP, the problem is that while they create superior lighting mood they effect the LG when we would rather they didn't. So my question is: Is there an arg or a script that can be applied to these BL's to stop them effecting the lightgem..?

Hello! I cannot open the light inspector. Either using dhewm3 or dm engines, the outcome is the same. Dark Radiant closes. running on terminal, this is the output: SIGSEGV signal caught: 11 0: /usr/local/bin/../lib/darkradiant/modules/libradiantcore.so(_ZN6applog15SegFaultHandler14_handleSigSegvEi+0x4ab) [0x7f767721e9eb] 1: /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f76818fd520] 2: darkradiant(+0x417db3) [0x55c1eb23cdb3] 3: darkradiant(+0x37f828) [0x55c1eb1a4828] 4: /usr/local/bin/../lib/darkradiant/libwxutil.so(_ZN6wxutil19DeclarationSelector26onTreeViewSelectionChangedER15wxDataViewEvent+0xbd5) [0x7f7682f942f5] 5: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent+0x6e) [0x7f7682bc117e] 6: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent+0x62) [0x7f7682bc4812] 7: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler11TryHereOnlyER7wxEvent+0x24) [0x7f7682bc48a4] 8: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent+0x3f) [0x7f7682bc495f] 9: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xa1) [0x7f7682bc4a51] 10: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler18SafelyProcessEventER7wxEvent+0xb) [0x7f7682bc139b] 11: /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0(+0x162e47) [0x7f768224ee47] 12: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x1290) [0x7f7680b14700] 13: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x7f7680b14863] 14: /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_tree_view_set_model+0x4e3) [0x7f76811aa283] 15: /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0(+0x151121) [0x7f768223d121] 16: /lib/x86_64-linux-gnu/libwx_gtk3u_adv-3.0.so.0(_ZN15wxDataViewModel7ClearedEv+0x2a) [0x7f76821b29da] 17: /usr/local/bin/../lib/darkradiant/libwxutil.so(_ZN6wxutil9TreeModel5ClearEv+0x16c) [0x7f7682f7d08c] 18: /usr/local/bin/../lib/darkradiant/libwxutil.so(_ZN6wxutil16ResourceTreeView5ClearEv+0x9f) [0x7f7682f6cd9f] 19: /usr/local/bin/../lib/darkradiant/libwxutil.so(_ZN6wxutil16ResourceTreeView8PopulateERKSt10shared_ptrINS_22IResourceTreePopulatorEE+0x162) [0x7f7682f71952] 20: darkradiant(+0x418488) [0x55c1eb23d488] 21: darkradiant(+0x4185fb) [0x55c1eb23d5fb] 22: darkradiant(+0x37d04f) [0x55c1eb1a204f] 23: darkradiant(+0x382cfc) [0x55c1eb1a7cfc] 24: darkradiant(+0x5d5345) [0x55c1eb3fa345] 25: darkradiant(+0x38e032) [0x55c1eb1b3032] 26: darkradiant(+0x392006) [0x55c1eb1b7006] 27: darkradiant(+0x39229b) [0x55c1eb1b729b] 28: darkradiant(+0x3976b5) [0x55c1eb1bc6b5] 29: /usr/local/bin/../lib/darkradiant/modules/libradiantcore.so(_ZN3cmd13CommandSystem14executeCommandERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorINS_8ArgumentESaISA_EE+0xa5) [0x7f76770aceb5] 30: /usr/local/bin/../lib/darkradiant/modules/libradiantcore.so(_ZN3cmd13CommandSystem7executeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x53) [0x7f76770b27f3] 31: /usr/local/bin/../lib/darkradiant/modules/libradiantcore.so(_ZN3cmd13CommandSystem14executeCommandERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorINS_8ArgumentESaISA_EE+0xa5) [0x7f76770aceb5] 32: /usr/local/bin/../lib/darkradiant/modules/libradiantcore.so(_ZN3cmd13CommandSystem7executeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x53) [0x7f76770b27f3] 33: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent+0x6e) [0x7f7682bc117e] 34: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent+0x62) [0x7f7682bc4812] 35: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler11TryHereOnlyER7wxEvent+0x24) [0x7f7682bc48a4] 36: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent+0x3f) [0x7f7682bc495f] 37: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xa1) [0x7f7682bc4a51] 38: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN12wxEvtHandler18SafelyProcessEventER7wxEvent+0xb) [0x7f7682bc139b] 39: /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0(_ZN10wxMenuBase9SendEventEii+0x83) [0x7f768280bea3] 40: /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0(+0x2f31f4) [0x7f768272a1f4] 41: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x16f) [0x7f7680af6d2f] 42: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x30c36) [0x7f7680b12c36] 43: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x11a4) [0x7f7680b14614] 44: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x7f7680b14863] 45: /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_widget_activate+0x5c) [0x7f76811b4cbc] 46: /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_menu_shell_activate_item+0x13e) [0x7f76810829ce] 47: /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x266ca3) [0x7f7681082ca3] 48: /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x3e6eb8) [0x7f7681202eb8] 49: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x1290) [0x7f7680b14700] 50: /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x7f7680b14863] 51: /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x3ae724) [0x7f76811ca724] 52: /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x251680) [0x7f768106d680] 53: /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_do_event+0xd3a) [0x7f768106e52a] 54: /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x39743) [0x7f7680d4e743] 55: /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x70f56) [0x7f7680d85f56] 56: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b) [0x7f7682d90d3b] 57: /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xaa6c8) [0x7f7682de56c8] 58: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x73) [0x7f7682d902b3] 59: /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main+0x9d) [0x7f7681064cfd] 60: /lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0(_ZN14wxGUIEventLoop5DoRunEv+0x25) [0x7f76826bb165] 61: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN15wxEventLoopBase3RunEv+0x31) [0x7f7682ae8e21] 62: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN16wxAppConsoleBase8MainLoopEv+0x5a) [0x7f7682ac4b0a] 63: /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_Z7wxEntryRiPPw+0x55) [0x7f7682b26b55] 64: darkradiant(+0x1782f2) [0x55c1eaf9d2f2] 65: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f76818e4d90] 66: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f76818e4e40] 67: darkradiant(+0x184f95) [0x55c1eafa9f95] I have a rtx 2060, running on Ubuntu 22.04, Kernel 5.15.0-56, Driver Version: 470.161.03. I updated the driver version and even gave full permission to the engine folders, but the output is the same.

Hey there, question - Is there a way to temporarily hide the "diamonds" in the rendered view without hiding the light effect? (for screenshot purposes) - pic attached. - DeeP

Been looking forward to this for ages but am very disappointed with the start. Dying Light 1 had/has the best climbing in any game I've ever played. BUT the start of Dying Light 2 is a scene where you have to climb up to a ledge. Two sessions and 90 minutes later and much frustration, I've still not succeeded. Endless failure is NOT the way to start a game! What am I missing? Move and jump. Fail. Move and jump. Fail. Move and Jump. Hey, I'm up a step! Move and jump. Fail. Move and jump. Fail. Move and jump. Hey I'm up another step! Move and jump. Fall. To my death. Start again. Repeat 50 times. In different places. I got within 8 metres of the guy above but still couldn't reach him. By contrast, the parkour training in DL1 was much more fair.

Not sure if it's a bug in DR or (most likely) TDM but I've been hit with this issue where a light ends up having different frustum vertices in TDM than it was set up in DR Map attached. Look at light_1 Its "far" corners seems to have the X coordianate of -125 When the light loads in TDM, the frustum corners can be rebuilt using different methods: R_PolytopeSurface gives -147 idRenderMatrix::GetFrustumCorners gives -213 This really messes up my volumetric shader Which one is supposed to be correct? idRenderMatrix::GetFrustumCorners is much farther from DR but R_PolytopeSurface's output is not even air-tight @stgatilov? @greebo Where can I find the code that calculates frustum vertices in DR? Maybe I should just copy-paste it in TDM and relax. volumetric.map duzenko.mtr

If in DR in light properties I set the light type to blamplight or blamplight2 and make it switchable via some switch, it does not go on or off via the switch. When I use blamplight_cv for example I can do that. I also found that if I change the color of the light, I don't see this in-game, there it's still white (if I've set it to yellow). Maybe this is normal for this type of light, but it should be in the description what it can and cannot do.

I'm not sure if this should go here or in the Tech Support section, so If this is the wrong place, please let me know. As a hobbyist game developer, I'm curious about how the Light Awareness System works in The Dark Mod. I've been poking through the source code, but haven't found any definitive math explaining it, or code comments mentioning on how it's calculated. If anyone could point me to exactly where to look, or could explain what steps and/or math it's using to calculate how visible the player is, I'd greatly appreciate the insight. For reference, I'm trying to implement a similar system in my own stealth game I'm working on in Unreal Engine 4.

Hello, the "Render in lighting preview mode" in Dark Radiant doesn't seem to take the ambient light into account correctly. But maybe I've set up something wrong as I don't think this wouldn't have been noticed. Ingame everything is correct, the problem only occurs in DR render preview mode. Let's say I set the _color value of the ambient_world light really high to make the ambient_world light definitely visible: classname: light name: ambient_world _color: 0.07 0.07 0.07 (which equates to a brightness level of about 18) light_center: 0 0 0 light_radius: 13115 13367 13570 nodiffuse: 0 noshadows: 0 nospecular: 0 origin: -8160 5872 56 (the actual map is far from the ambient_light but within the ambient light range) parallel: 0 texture: lights/ambientlightnfo When I now activate the "Render in lighting preview mode" in DR, only the brush faces pointing towards the ambient_world light are getting brighter, brush faces not pointing to ambient_world remain (incorrectly) dark, as if ambient_world was a regular light. The house front you see in the background also points towards ambient_world and is lit. House fronts "behind the camera" as well as the floor are dark. Can I do something to make ambient_world work correctly in render preview mode? Additionally: Is it possible to setup lights, so that they only render in the editor, not ingame? That way I could make two fake ambient_lights, one at 15000 15000 15000 and one at -15000 -15000 -15000 to light all surfaces in the editor and light them a little bit brighter than ingame for better visibility in render preview mode.

The next 2.08 beta update is going to include a new Bloom effect and the ability to render to a floating-point (HDR) buffer. While that may sound very technical, it gives you new options to represent bright light sources in your maps. As an example, look at this screenshot courtesy of @peter_spy: No particles effects are involved. The lamps have a simple blend add stage with a texture and an 'rgb 20' factor, which means that the color values of the texture are multiplied by 20. They will therefore exceed the normal color range and go into HDR range. And while they will eventually be clamped back down to the standard [0,1] range and thus appear white on the screen, the new Bloom effect collects these values, blurs them and adds them to the final image - that's what gives the lamps that glow and makes them look bright. So, if you'd like to play with that, with the next 2.08 beta you'll be able to enable Bloom in the advanced settings under experimental features and also set the color precision to 64 bits (float). Hope this will give you some new options to accentuate your lights Or if you're impatient, you can try this build: https://ci.appveyor.com/api/buildjobs/at3a0wyvy3kgt0ep/artifacts/TheDarkMod.7z (The downside, of course, is that both Bloom and 64 bit color precision are not going to be on by default in 2.08. If they are off, the lamps will just appear white without glow.) Btw, aside from that nice glow around over-bright light sources, the higher color precision won't really make much of a difference. But it does help with banding artefacts - fog and similar things will look noticably smoother.

Тest: Thief's Den 3: Heart of Lone Salvation Settings: by default Version: 2.09 Bug description: While the player is moving, if he look at the floor, he can see a wave of light. This wave of light moves with the player, as if the player is the source of this light. Example. stand at the specified point, go forward till the next point and at the same time look at the area marked with a white line.

I have a performance issue with an FM that working on. The FPS is dropping pretty low in some areas. I narrowed it down to the fact that my light counts are high (r_showlightcount 1). I'm confused why certain lights are contributing to the light count. To help understand this issue, I just created a simple test case, which consists of: Main room with a light. Hallway connected to main room Stairway down connected to the hallway Basement room (with a light) connected to the stairway. The basement room is directly below the main room. There is a visportal and door between the hallway and the stairway. When this door is closed the light count in the main room is 1. When it is open, the light count is two. I hope this video makes it clear: This puzzles me - how can the basement light affect the light count in the main room? The light shouldn't be going through the floor/ceiling between the two rooms, right? Why does opening the door make a difference? The door is beyond the range of the light anyway. Additional data point: It doesn't matter what type of light I use in the basement, the behavior is the same. Any light based on atdm:light_base shows this issue. But, I replace the basement light with an object of class "light" (the thing you get if you do "Create light..." in DR), then the light count stays at one even if the door is open. In fact, I was able to create a light that looks and acts just like the atdm:cagelight. I went through the class hierarchy, starting with atdm:cagelight, then what it inherits (atdm:static_electric_light_unlit_base), then what that one inherits, and so on, and I grabbed all of the spawnargs from each. I ended up with this: { "classname" "light" "name" "light_2" "AIUse" "AIUSE_LIGHTSOURCE" "_color" "0.44 0.34 0.17" "editor_SetKeyValue s_shader" "light_flicker_104" "editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Outdoor/DoNotUse" "editor_light" "1" "editor_setKeyValue light_center" "0 0 -8" "editor_setKeyValue model" "models/mapobjects/lights/cagelight/cagelight.ase" "editor_usage" "A lit wall-mounted, grill light. Replacement for Doom3 cagelight. Can be toggled on/off when linked from a switch." "extinguished" "0" "lightType" "AIUSE_LIGHTTYPE_ELECTRIC" "light_center" "0 0 -8" "light_radius" "260 260 260" "model" "models/mapobjects/lights/cagelight/cagelight.ase" "nodiffuse" "0" "noshadows" "0" "noshadows_lit" "1" "nospecular" "0" "origin" "-848 -136 -736" "s_looping" "1" "s_shader" "light_flicker_104" "s_waitfortrigger" "0" "scriptobject" "tdm_light_holder" "shouldBeOn" "0" "skin" "lights/cagelight" "skin_lit" "lights/cagelight" "skin_unlit" "lights/cagelight_unlit" "sr_class_1" "S" "sr_radius_1" "500" "sr_state_1" "1" "sr_time_interval_1" "977" "sr_type_1" "STIM_VISUAL" "texture" "lights/tdm_lanternlight_4fold_small_snd" } Which is equivalent to atdm:cagelight in both looks and function. The difference is, this light doesn't add to the light count. I suppose I could use this to work around the issue, but man is that kluge-a-rific. Anyway, any ideas on what is happening here? The test map is attached. testl2.zip

I have never seen guards light candles or torches extinguished by a player.... have you seen it? If this is not the case, can to add support?

While doing some render system refactoring I noticed that projected lights were not rendering correctly in lighting preview mode, and thought it was something I had broken until I regressed to earlier revisions and discovered that it has actually been broken for some time (in fact I tried checking out revisions from 3 years ago and the problem still reproduced). Projected lights are something of a "bug trap" because I think most mappers don't use them or the DR lighting preview very much and therefore they don't get a lot of testing. The behaviour I see is that while the rendered light projection obeys the shape of the frustum (i.e. the light_up and light_right vectors), it seems to ignore the direction of the light_target vector and always points the light straight downwards. The length of the target vector has an effect (on the size and brightness of the light outline on the floor), but the direction is ignored. Note that the problem only applies to the rendered light itself. The frustum outline appears to be correct (as it is handled with different code). I believe the problem is with how the light texture transformation is calculated in Light::updateProjection(), although I can't be sure. I will make an effort to debug this although projective texture transformations are near the limit of my mathematical abilities (I can understand the general concept and probably figure out the process step-by-step by taking it slowly), but might have to ask @greebo for assistance if the maths becomes too hard. Another approach is to try and revert the relevant code back to when (I think) it was working correctly after I initially got projected lights working, although that might have been 10 years ago or more so a straight git bisect isn't practical.

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is. Sorry I probably wasn't clear enough with my initial post. The attached snippet shows a typical electric light source, and you can see the light origin is the exact same location as the origin of the model. The issue's are - if I dont use def_attatch I can't change or move the light_origin, which means for example a shader with a pattern (tdm_lantern) with directly under the origin of the light, not the light_center which idealy where you would want it.So then a mapper would then use def_attach so he/she could change the location of the light_origin eg "def_attach" "light_candleflame_unlit" "pos_attach" "flame" // At the attach point called "flame"... "attach_pos_name_1" "flame" // ... which is defined here. "name_attach" "flame" // Give it a name to pass along spawnargs "attach_pos_origin_1" "0 0 10" // Offset the origin of the light/flame X number of units in the Z direction "light_center" "0 0 20" // Offset the center of thelight/flame X number of units units in the Z direction "light_redius" "130 130 130" // size of the light radius "texture" "lights/biground_candleflicker_shadow" //shader for the light souce "_color" "0.80 0.6 0.23" //colour of the light souce And now I have just realised what i was doing wrong, which was causing TDM to ignore my "light_radius" in-game. I was using "light_origin" instead of "attached_pos_origin" and this was because I thought it would be the same nomenclature as 'light_center' and 'light radius'. The issue with def_attach is that the mapper can't then change the origin in DR, its has to be done in the .DEF file for that entity. Or they can force change the setting in DR using the following args - // Flame "set light_radius on flame" "100 100 100" "set color on flame" "set s_volume on flame" "-20" "set attach_pos_origin on flame" "0 0 0" "set _color on flame" "0 0 0" // light "set light_radius on light" "100 100 100" "set color on light" "set s_volume on light" "-20" "set attach_pos_origin on light" "0 0 0" "set _color on light" "0 0 0"As some have mentioned in this thread, it would be nice to be able to change the above setting in DR using normal methods, not args. I guess the only way yo do this is for DR to create new definitions? like it does when you modify or create new particles?

Hello, Recently while doing some stuff with light i asked myself a questions: For the sake of immersion, should dark caves with 0 light sources be pitchblack? You can ask this question multiple games: We see Ambient light in Skyrim in nearly all caves/dungeons- I cant remember a single moment in thief [1,2,3] where there was full darkness. Amnesia has ambient light in only a few levels, the rest is completly dark. Splinter cell uses full darkness in only a few spots. What do we do here, TDM doesnt use full darkness either. Can we talk about why we use ambient light? And why cant dark caves not be fully dark? Should we have a setting for ambient light? Please tell me what your experiences are i cant decide on what looks/is better. I like this light more: https://www.nexusmods.com/skyrim/mods/72594

Not so long ago I found what could make a pretty good profile picture and decided to try it out on these new forums. But I couldn't find a button anywhere that would let me change it. I asked on Discord and it seems Spooks also couldn't find anything anywhere. So I logged into an old alternative account and, lo and behold, that account has a button. This is on the first screen I get when I: 1) click on my account name in the top-right of the browser -> 2) click on 'profile'. Compared to my actual account: Are you also missing this button on your account? It'd be very much appreciated if that functionality could be restored to any of the affected accounts.