Search the Community

Hello! I just upgraded my 2.06 Darkmod to 2.07 and have experianced following issues. Bottom half of the main menu flickers when moving mouse. When playing Tears of st. Lucia most of the lights are not lighting up anything. You can see the model for the light is lit but no light is emmited. I just returned to Darkmod and am unable to play at this point. Couldn't find any similar post, checked FAQ. I uninstalled the game and installed it again fro scratch, as well as removing anything from %appdata% and the problem remains. Please help! Thanks, Neux

Hi I have a weird issue with playing the mod. All lights except for the ambient lights are not working. See attached image. This happens in all the missions I tried today. The light gem doesn't light up and guards cannot see me if i move closer to a light. If I use the lantern the light gem becomes bright but there is no light in my surroundings from the lantern. So I reinstalled tdm completely and I updated my nvidia geforce drivers but the issue remains unfortunately. Anybody has an idea what causes this?

After a long time and a lot of delays, I'm extremely happy and relieved to announce the release date for my first map; Lords & Legacy, on Friday the 30th of August, 2013! Lords & Legacy v.2.1 Resume: Screenshots: http://imgur.com/a/Lj8UJ#0 Notes: Build time: 2013/03/30 - 2013/08/30 To install, simply put the .pk4 file in your fm folder and install from the in-game mission menu. It is a large mission with optional objectives, so make sure to save often. The ropes in the beginning have a 'slick' surface, to simulate being 'slack lines'. They are difficult, but once you get a hang of the slide they can be fun. A couple of the large areas can be a bit rough on performance, and can be improved by adjusting the LOD slider in video options. A few of visportals open only when you get close. This is to keep the frames smooth inside the respective building, due to early inexperienced design. If you find any bugs which affect the gameplay experience, then you're very welcome to post them here, but please use the spoiler tags. Big thanks to 'Obsttorte', 'Springheel', 'Greyman', 'Bikerdude', 'Sotha' and rest of 'The Dark Mod Team'for all the help, guides and tricks. Also thanks to the other TDM users who provided fantastic support and feedback during the build. Thank you for beta-testing: 'Bikerdude', 'TylerVocal', 'Simplen00b', 'nbohr1more', 'Briareos H.' Special thanks to: 'Danus', 'Dsx' & 'Stanleh' for testing, help and support. v.2.0.1 changelog: Bugs: -The "Master Thief" challenge was impossible to do for a while, due to incorrect values. Fixed. -Getting seen by "The Killer" now also fails the "Ghost" challenge. -The 3 cardplaying guards no longer float mid air, as their chairs are now nailed to the floor. -Fixed the sound of the furnace continuing after the flames were extinguished. -Fixed weird glittering on the power cables around the map. -Fixed some moonlight popping in and out. -Fixed openable windows in Commons, clipping into the frame. -Fixed a book dropping through a desk. -Fixed visportals closing too close in Lancel's Tower, slight hit on performance though. -Added more monsterclip to Service Tower and Robert's Tower's entrance. -Improved a few vis_portals with func_portals. -Replaced curbs in Slums and Commons with some more detailed versions and changed textures. And a lot more little unecessary tweaks. Gameplay: -Added new challenge: (Jack White) - Do not knock-out anyone. -Reduced the amount of starting gear, depending on difficulty. -Added cubemaps to most windows on the map. -Redid most func_statics in Commmons Quarter to reduce tris and increase performance. Draw count is still somewhat high. -Removed all transparent windows as they didn't have actual gameplay value, just a performance drain in exchange for glitchy visuals. -Lancel's safe can no longer be picked. Find the key! -Added a couple minor cosmetic details in the sewers. -Moved a coinpurse from a wealthy commoner's sleeping butt to his nightside table. Also adjusted his furniture so thieves can better move around. -Changed sounds for several doors across the map. Once again, a big thanks to 'Bikerdude' for taking the time help out and locate room for improvement! v.2.0 changelog: Bugs: -Fixed various textures and surfaces and a few minor tweaks. -Tweaked some sounds to be in line with TDM 2.0 changes. -Fixed 2 certain AIs being too sensitive rather than drunk. (Thanks to AluminumHaste!) -Tweaked LOD on some objects, to prevent windows "popping" in and out. Gameplay: -Added more monsterclip to the towers, so the AI can now run up and down stairs. Only the stairs in the small tower has issues still. -Added more monsterclip in the city so the guards can follow you up all stairs. -Added a few minor details. -Windows in the city now dims sound, resulting in less aggro from guards and more convincing soundscape. -Reduced 'draw calls' in all the large areas, increasing performance. The map is still heavy at certain areas. Another big thanks to 'Bikerdude' and 'Greyman', for taking time out of their own schedules to help optimize the map's draw count and other significant adjustements! v.1.0.3 changelog: Bugs: -Fixed 4 black chairs in one of the towers -Fixed a floating painting -Fixed several clipping objects v.1.0.2 changelog: Bugs: -Fixed zfighting in the library's bookshelves -Fixed a black window in one of the towers -Fixed several typos in readables Gameplay: v.1.0.1 changelog: Bugs: -Fixed an issue with the main objectives not being in "sync". -Fixed console spam from a script Gameplay: -Adjusted required loot for each difficulty from "3000, 4000 and 5000" to "2500, 3500 and 4500".

Not sure you understand the feature. That transparent geometry IS WHY these these are called "volumetric". All Doom 3 \ TDM lights use light volumes but the new "volumetric" lights are meant to render God Rays, light shafts, etc by filling the light volume with transparent dust \ fog. When you disable the volumetric feature the lights go back to being standard TDM lights with no God Rays and dust. The other rays and dust in the scene above are made by particles and patches.

Wow! This is something interesting. You have areas 177 and 179 (you can detect them using teleportArea command) with 8 visportals between them, all in same plane. I hope this is as intended, and you really have many separate visportals? This should be perfectly valid of course. FloodLightThroughPortals searches for all visportal sequences which might get some light rays through. For some reason, it manages to go back and forth between areas 179 and 177 something like eight times in the same sequence. It is not forbidden for the traversal to go through the same area many times, but it is forbidden to go through oriented visportal twice. However, there are too many possible sequences of going through 8 two-sided visportals, and the code obviously tries to enumerate and save them all. At some point it bumps into 32-bit integer limits and everything crashes. By this moment it has wasted 32 GB of RAM so I don't think it would live long even if it did not crash here. You don't have the issue in 2.11 because: This is a dynamic light from some lantern bot, TDM 2.11 only runs this function for static lights. TDM 2.11 does not try to save all sequences, it would only enumerate them in horrendously slow time. I think some lantern bot crosses the visportal between areas 179 and 177 at this moment, causing the issue. Also, you can most likely reproduce it in 2.11 by putting a large enough light at the same location (12565.0205, 411.300110, 522.249939).

Of course I'm not talking about the flames, but the electric/gas lights or whatever they are that always remain lit. It can have balance like attract a guard from the break sound or require a special tool. I just find the fact that they're impermeable yet the fire lighting is so easy to take out a bit of an odd thing.

Not to be a nag, but I was thinking about the columns problem. If you go to the view source tab in the wiki article: https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod&action=edit The raw table data is accessible directly: |- !align=left|{{TDM-FM|written|Written in Stone}} |Bikerdude, Amadeus, Dragofer |{{Forumlink|https://forums.thedarkmod.com/index.php?/topic/21265-written-in-stone-beta-210-only-20220128/}} |2022-01-28 |338 |Yes |Yes |CCC 22, Elixir |City Missions |Undead, Horror Themes |- Each pipe character represents one of the columns.

xash3d a half-life clone engine was also based on darkplaces though on a much much older version than what is currently up for grabs. had they used the newer engine then xash would be close to source engine levels of photorealism but the newer engine sources are pretty hard to work with if you are not into toying with the darkplaces source code regularily mostly because the code no longer resemble the quake source code anymore. It was also the first quake engine to support portal culling though not the first to support real time lighting and bumpmapping that honor goes to tenebrae, havoc did catch on quickly though and his implementation was far superior to the tenebrae model which used hacked entity lights (sprites basically). darkplaces uses rtlight a variant of the old lighting tool from quake supporting real time light sources, quake itself does not however support realtime lighting so the lightsources are parsed from an external rtlight file containing the positions of lightsources in the map if you dont have these it can approximate the lightsources much the same way as tenebrae did but it is very very VERY slow, in mods it can be compiled into the map. it also supports bsp2 a new map format allowing much more complex levels and a skeletal model format instead of the blocky mdl1 format. havoc has not had much time to do work on darkplaces in later years (works for ID software now) and got married some years back to one of the other devs from the now defunct inside3d where i used to frequent, but i heard she would probably take up work on it again shortly. Would be rather cool to see where that might lead having worked with the ID dev'ils she might actually make an engine that becomes a serious contender to them heres a shot from quake 1 with all the mod bells and whistles on skeletal models real time lights hd textures you name it it is probably there.

Terrific! The beta test thread is up: https://forums.thedarkmod.com/index.php?/topic/22238-beta-testing-the-spider-and-the-finch/

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

Welcome to the Dark Mod forums MarsManon! Thank you very much for the kind words about SLL, it's always nice to hear We all worked real hard on bringing Grayman's map to life and I'm glad you enjoyed it

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

I reported about this a lot during beta testing and some of these got fixed I think. I think the reason is that the mission has a lot of noshadows lights, for better performance. Source Possibly with the performance improvements in 2.11 (stencil shadows + Ai processing) it's not needed to have so many noshadows lights in there. Fixing whould also make the mission look better. I'm sorry to hear, hope you recover soon.

Nice walkthrough, i made it in Hard mode, entering in the sitedoor, which i think is somewhat more tricky than with the Ropearrow (not disp. in the Hard mode), Without KO nearly impossible, at least for me. I made it with 782 loot and 0 stealth. Inside is easy, normal stealth level, also~20 min. In the Bar no stealth needed, at least when you don't rob the coins of the card player, they don't like it with the lights on. Also don't try to frob the Key for the Main entrance, not healthy with a Guard with torch, who turns in a half second without the key.

Thanks: will look at the lights changing - that might be the same ambient thing that happened in the square I've fixed the readable already for an update I'm getting ready the pool - the lights are magic

I think I found a way to settle this. Managed to put together a script / addon which emulates this functionality. The advantage is you can use it in any FM: Drop the pk4 directly inside your TDM folder and it will automatically work. Two versions are provided: One turns the light off entirely, the other only disables its shadows... don't use both at once but pick one. Just remember this is a testing script and will break your run! For one it doesn't know when a light is meant to be turned off, thus will enable even lights that started or were toggled off once they're in range... meanwhile the nowshadows version enables self lighting on torch models which looks wrong. They also seem to cause infinite loop crashes on occasion, though it should take long enough for them to occur in order to obtain a result. light_dist.pk4 light_dist_noshadows.pk4 // Test script for hiding lights with distance #define DIST_TORCH 1024 #define DIST_GAS 1536 #define DIST_ELECTRIC 2048 void light_dist() { while(1) { // sys.waitFrame(); sys.wait(0.5); player ent = $player1; entity ent_find; // Do torch lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_TORCH", ent_find); if(ent.distanceTo(ent_find) > DIST_TORCH) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); // Do gas lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_GASLAMP", ent_find); if(ent.distanceTo(ent_find) > DIST_GAS) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); // Do electric lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_ELECTRIC", ent_find); if(ent.distanceTo(ent_find) > DIST_ELECTRIC) ent_find.Off(); else ent_find.On(); } while(ent_find != $null_entity); } } // Test script for hiding lights with distance #define DIST_TORCH 1024 #define DIST_GAS 1536 #define DIST_ELECTRIC 2048 void light_dist() { while(1) { // sys.waitFrame(); sys.wait(0.5); player ent = $player1; entity ent_find; // Do torch lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_TORCH", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_TORCH); } while(ent_find != $null_entity); // Do gas lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_GASLAMP", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_GAS); } while(ent_find != $null_entity); // Do electric lights do { ent_find = sys.getNextEntity("lightType", "AIUSE_LIGHTTYPE_ELECTRIC", ent_find); ent_find.noShadows(ent.distanceTo(ent_find) > DIST_ELECTRIC); } while(ent_find != $null_entity); } } With the defaults I balanced it at, I admit I'm not all impressed with the result on my FM: The popping is noticeable and the performance improvement doesn't feel as radical as I would had hoped even if it's there. With r_showprimitives it does seem to kick about 300.000 triangles off when fully disabling the light which doesn't seem too bad... not giving any more verdicts this way though, I'll let the devs play with the script and decide what to make of it.

Regardless of what is used in the end, I think we should move auto-loot to that too for everything to be consistent. Right now auto-loot is long-frob, bodies and lights are double-frob and consumables are frob+use! Rather an unintuitive mess.

With actual raytracing being a long time away from even being imaginable in our engine, I've become a growing fan of simulating bounce lighting with the conventional lighting system we have. It's good for realism and because I love that warm soft light emanating beyond walls from one candle in a dimly lit area behind. TDM currently has no global illumination, the only form of estimating GI being a constant light that changes per area based on the amount of lights in that portal zone (great system but not enough). Today it just occurred to me that for starters, it wouldn't be that hard to attempt a simple yet more effective estimation. Initially I was going to write a script for it before realizing I could just do this via defs alone! The rule is simple: For each normal light, we attach a secondary light of roughly the same radius, textured with a low-intensity ambient light (lights/ambient_biground) to simulate directionless diffusion with minimal impact on performance. I wrote one def for my bounce lights and another to override all of the builtin light types and attach the appropriate one and that was it! Kind of, it's never that simple. Here's my patch in its initial form and a few screenshots of what it achieves, mainly noticeable as a dim light showing through the shadow of the standard one. tdm_bouncelight_v1.0.pk4 Of course it's not all rainbows and sunshine. As you probably expected, this approach has the fatal flaw of lights shining through walls as the area lamp casts no shadows. This looks horrid from other angles where you see walls being lit out of nowhere by sources on the other side. That's the result of candles and torches shining through the floor from other rooms... not okay and unfortunately a deal breaker until I found some way to fix it. Apart from this it appears that with a lot of lights in more complex maps, performance takes a considerable hit while even freezes and crashes are being introduced by the extra lights... I find this strange given ambient lights cast no shadows nor do they do per-pixel calculations like specular or normal mapping, and most don't even move so shouldn't they be cached? I don't know to what extent it would be a waste of time to approach this further: On one side it's a tedious task and my hope of getting it to work with just one extra light is naive... on the other side as you can see from the first batch of screenshots, it can look gorgeous if done right, this gives us a glimpse of what we could have with a proper system. Normally this needs to be coded in the engine to get any sane results anyway, especially as this setup calculates no actual bounces just adds a radial glow to estimate it, surfaces don't colorize the light and there isn't any real bouncing going on in any form. Of course I don't have a fraction of the knowledge to do that, and I'm not gonna be this cruel to @cabalistic and other graphics devs to suggest this after all the other exciting yet difficult ideas I've been bringing up. What are your thoughts on this? Can you suggest any tricks to fix the lights going through walls when they shouldn't, or perhaps a better approach altogether? Maybe I can define my own light texture to reduce wall leaking but not destroy the immersion otherwise?

I played both test versions with "The Bakery Job" and as everybody could guess, I like stgatilov's version better because it is consistent. I don't see why daft's version should be more intuitive, especially as shouldering bodies and extinguishing lights are working in opposite ways. Still I believe that without a tutorial or key binding hint, no new players will discover either version on their own as double-frob and long-frob are not used elsewhere. stgatilov, is it possible to make both double-frob and long-frob work in your version? Also to really make this consistent, could you add eating food on double frob too, please?

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