Search the Community

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.

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

You'd be better off setting them up as entities — that's what entities are for after all, creating interactable objects with whatever sub-models and entities/lights/emitters are needed to make them work. You could look at some of the existing entities (within the def virtual folder of the core assets) and use that as a template. Once you've done this, you can just right-click, Create Entity and choose your new lamp to place one in the mission. Another option is to export them as prefabs, which you can then import using DR's menu wherever you like. This is probably easier to set up than creating a custom entity, but it will be slightly heavier on the map file (because each prefab will have its own copy of the light+emitter combo, which all need to be saved into the .map file). However entities by themselves do not require massive amounts of data, so this is still a workable solution. That wasn't really the point of the comparison. TPW is one of the largest maps ever, and wasn't particularly well optimised at release (although its second version was considerably improved). The vast majority of maps are considerably smaller, especially first releases by new mappers which tend to be less ambitious than large team projects. Releasing something larger than TPW isn't necessarily broken and it doesn't mean that people won't play the mission. But if your map isn't actually designed to be huge (e.g. a massive outdoor city area with numerous playable houses), and it still results in a package which is much larger than the current largest mission(s), this does suggest that there is some problem which optimisation or data storage which might cause other issues when people try to play it.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

PLAYERS 1) A lot of effort was put into optimizing loading times. It includes: better integration of decompression, multithreading, immutable texture storage, handwritten normal map compression and mipmap generation, removing artificial delays. As the result, we even had to modify loading screens of some missions, because allocated 10% of loading time was no longer enough for a player to read the hint 2) Generic performance improvements were done too. Most importantly, we fixed performance regressions since 2.07: rendering static geometry (5598) and soft stencil shadows with antialiasing. This hardly makes a difference, but it is nice to know that TDM can now use AVX instructions on Linux builds too. 3) We made some changes to window / input systems. Most importantly, Linux build now relies on GLFW library to create window and handle keyboard / mouse (thread), so a lot of the issues with OS integration on Linux should go away. On the Windows side, some minor changes were made to fullscreen/borderless modes. 4) New implementation of object dragging / manipulation (thread) Afraid to grab a candle near a sleeping guard? Hopefully, you will make less noise while moving objects in 2.10. And if you hold the creep button, the moved item will not make any noise at all. Also, dragging unconscious bodies should feel better now. Rats slighty spoiled the joy of this improvement (rats often do), but hopefully it is fixed now Finally, now you can control how far a rock flies by holding throw button for a different amount of time. 5) New visual style for frob-highlighting objects. This point is still surrounded by debates though (thread, poll), so the fate of the frob outline is yet uncertain. 6) Tooltips are now shown in the main menu. Perhaps the text is not perfect yet, but this is a birth of the long-awaited feature! 7) Tweaked starting new mission in the main menu. The old way of "installing" and starting missions was quite confusing for newcomers. So we reorganized the main menu a bit, and now it is hopefully more intuitive. MAPPING 1) Entity limit is no more (thread). Well, number of entities is technically capped by 65536, but I don't think it can be reached by ordinary mapping. You should no longer use the insane tricks of the past striving to reduce the number of entities (unless the tricks have other benefits, of course). 2) Behavior of spotlights (projected lights) reverted back to how they worked in 2.07. It means that the missions released before 2.08 should now look as intended. The sad thing is that the missions with projected lights tweaked for 2.08 or 2.09 are probably a bit off now. Also, fixed a bug that spotlights illuminated surfaces outside their light volumes. 3) Security camera improved. Security cameras have been reworked from the ground up with the aim of bringing them to the same level of polish as TDM's AIs, both when it comes to stealth gameplay and how mappers can work with them and customize them. Most importantly, security cameras in new FMs will track the player once they catch sight of him rather than freezing in place, making them considerably harder to shake off. All the details can be seen on the wiki page. 4) Volumetric lights can now be used on projected lights (thread). Unlike adding fake translucent geometry, the real volumetric lights automatically match their source light, including light volume geometry, projection & falloff texture, and even shadows. Full description of available settings is available on the wiki page. 5) X-ray screens feature added. This feature that was originally in Doom 3, has been reintroduced to TDM and developed further. The screens are able to change the appearance of entities seen through them, even making them appear or disappear if desired. Look out for them in future Inventors Guild and magical themed FMs. You can find the thread here with links to the relevant wiki articles. l 6) Added a system for tracking secrets. Now it is easy to set up, with no custom scripts required. They'll also be shown on the mission statistics screen at the end of the mission, if the FM uses the new system. More can be read on the wiki page. 7) Main menu GUI has been reworked to allow more customization. Mappers can change music, background, disable screens in the uniform way. Debriefing videos work exactly as briefing videos do. The same customizations can be applied to ordinary missions and separately to every mission in campaign. You can find more details in guis/mainmenu_custom_defs.gui inside tdm_gui01.pk4. A lot of the released missions were updated to use the new customization system (thread). Which unfortunately means that their customizations won't work in 2.09 and earlier versions anymore. 8| Dmap times have been reduced (thread). Optimizations were made all over the dmap code, adding some new algorithms and data structures. Of course, the time difference varies between maps. As a side product, precision has been improved in a few places. 9) Added location diagnostics to dmap (thread). Setting up location entities and separators is an error-prone process, and previously there was no good way to find the error. Now dmap will post warnings and even produce pointfiles in case something is wrong with locations, similar to already existing visportal diagnostics. 10) Added native support for PNG image format. Now PNG images can be used in materials. In some cases PNG is a good alternative to TGA for uncompressed images. Note however, that loading PNG is slower than loading TGA, and we have yet to discover if this is a problem or not. As a side note, DDS images can now be used in image programs, although doing so is discouraged because of additional loss of quality due to compression. 11) Subtitles can now be assigned to sound files (thread). While implementation is a bit raw yet and needs to pass test of time, subtitles have already been added to Saint Lucia prebundled mission. Note that we did not consider localization of subtitles yet (localization as a whole is in weird state in TDM). Full description is available on the wiki page. 12) New script events have been added to the repertoire for use by mappers: a) sys.VecRotate( vector vec, vector angles ) rotates a vector by a set of angles, allowing to match vectors such as offsets to an entity's current orientation. b) entity.getEntityFlag( string flag ) allows to find out properties about entities such as "notarget" (for the player entity) or "invisible". c) $player1.getCalibratedLightgemValue() retrieves the current value of the lightgem, using the same weighting as AIs do. d) entity.setSolid( boolean state ) allows to change the solidity of an entity at runtime. Note that it's still experimental. e) sys.getLocationPoint( vector point ) returns the location of a point in space. f) sys.pointIsInBounds( vector point, vector mins, vector maxs ) evaluates whether a point lies within a volume specified by 2 corner points. g) sys.getTraceSurfType() returns the type of surface the most recent trace has hit, such as "snow", if any. *) Some other improvements: a) Supported "set XXX on head" spawnarg on AIs. b) Some LOD improvements, e.g. for lights. c) Hot reload supports more of the popular spawnargs (i.e. without respawn). d) In-game downloader can update the currently installed mission. ASSETS 1) Automaton AI from Ulysses mission by @Sotha have been added to core, together with new prefabs for (cosmetic) recharging stations to include in patrol routes and a camera screen showing what the automaton sees. 2) @Wellingtoncrab contributed a whole new suite of fancy wooden furniture pieces including prefabs. They can be viewed in their release thread. PROGRAMMING Some interesting things happened on programming side too. First of all, the limited GL profiling has been replaced with Tracy profiler, which has its own cool viewer. It has greatly helped us in our optimization efforts. More technical stuff: generic hash table has been added, Clear in idlib method now works as most programmers expect, unit tests integration has been improved. Another major event that happened this year is migration to the new mission database, based on SVN repository. Hopefully, there will be less confusion about mission updates, and old versions of FMs will not be lost anymore.

Hidden Hands: Initiation Download via the ingame downloader. Latest update is version 3 (released 16/02/2021) Explore Blackstone Island to become a full-fledged member of the “Hidden Hands”! General: TDM version: 2.06 EFX: yes Play time: ca. 5 – 7 hours (depending on play style and difficulty settings) Type: island with several sections (manor, sewers, cabin, bank, graveyard, church and crypts) Enemies: guards, thieves, spiders, mages and extra-natural entities Known problems: 1. The noblewoman sitting in the pavilion can sometimes not be knocked out without failing the mission in general; decent thieves should leave her alone anyway. (version 1 and version 2) 2. If combination locks do not work when using correct codes, then please go to Settings - Gameplay - and change the option "Open doors on unlock" to the value "yes". (version 1) Gameplay differences (apart from changes in the objectives list): Easy: Less enemies, less lights, many light switches Medium: More enemies, alternative AI routes, more lights, some light switches Hard: Even more enemies, alternative AI routes, even more lights, less light switches Development: Build time: November 2017 – November 2018 Beta testing: November/December 2018 Beta testers: Boiler’s_hiss (aka “The Architect’s Darling”) s.urfer (aka “The Punisher”) Cambridge Spy Abusimplea Performance checks: Duzenko Contributors: - ERH+ arranged/created the setup for the puzzle in Adrian's Crypt - I don't understand what he did exactly (alchemy?), but it works as it should. - Destined provided a custom skin for an interior module and wrote a new definition for the spider bots, enabling those beasts to move through tunnels. - Joebarnin provided a fix to make the combination locks work. - Amadeus revised and edited all in-game readables, maps, and signs. He created the final mission title "Hidden Hands: Initiation" as well as gave some special items heroic names, such as "Axe of Fury" or "Orb of Will". - Grayman fixed the frobbing problems with the hidden wall safe and combination lock. Pilfered items: - Floating boat setup and thief's message box re-created from maps originally developed by Bikerdude. - Patch section with rocks and vegetation surrounding the graveyard originally developed and arranged by Sotha for one of his missions. - Frobbox booster re-created from a map originally developed by Grayman. Special thanks to: - Springheel, Sotha, and Fidcal for the tutorials. Great work from all of you! - Destined, Grayman, ERH+, and Springheel for patiently answering my questions via PM. - Boiler’s_hiss for the hint how to change the church roof section - nbohr1more for moral support during a critical phase of the map development - Duzenko for improvement tips - all others not mentioned here who answered my questions in the Newbie thread or via PM. All new ambient music and sound effects written, performed and mixed by Jack Farmer. "S.urfer's Lament" (.ogg filename: "easyexit") featuring MC Deickler on the drums. More pictures:

Indeed, this new segment in ::init of the tdm_light_holder scriptobject applies the _color of the parent entity to everything bound to it, if the spawnarg "propagate_color" is set to "1": if ( getKey("propagate_color") == "1" ) { vector col = getVectorKey("_color"); for (ind = 0; ind < numBindChildren(); ind++) { child = getBindChild(ind); if( child ) { child.setColor(col_x, col_y, col_z); child.setKey("_color",col); } } } I would only apply this script to new entities with the propagate_color spawnarg, and only make the new entities recolourable, for a number of reasons: There are bound to be a lot of light holders across TDM's missions that have leftover _color spawnargs from when the mapper was trying to work out how to recolour the def_attached lights. If this starts to take effect, it may unpredictably change how those missions look or play. The _color spawnarg isn't fully as realistic as having a pre-coloured particle image, in part because of the additive effect. You can see here how at default particle settings, this blue-coloured flame is incredibly bright. Recolourable particles will therefore need fewer than the default 12 cards to still look reasonably realistic. From a visual perspective it'd be ideal if we had one duplication of our light entities per pre-set colour, but this would be extremely cluttered. I think we can justify 2 sets of entities: standard flames and recolourable flames. Generally we're quite stringent about avoiding changes to existing assets that could alter or break released missions, preferring to create new entities. Being able to recolour any standard light with a single spawnarg would be great, rather than using a separate set of entities, but it'd have far-reaching effects for TDM's missions.

I recently saw discussion about PBR materials being added to Doom3BFG with folks also talking about it on Discord. One of the things I always wanted from PBR is proper reflections, especially in a way that works on all FM's new and old without requiring changes (eg: new light entities). Lack of proper reflections is one of the biggest limitations we still have, leaving us with mere boring specular reflections lacking any detail. While currently we can't have things like metallicity or per-pixel roughness, not even the ability to use the skybox or player camera feed as a reflection map, we do have a generic cubemap used only on windows and a few special textures. So the thought itched me: What if we could make every material with a specular map also blend a cubemap reflection? I've done Linux batch scripts for complex tasks before, so after lots of searching (and dealing with DOS era line terminations getting in the way) I managed to create a bash script that will do just that! This 50 line script will detect all materials with a specular map, inject a customized cubemap reflection, then repack everything. It scans every material in TDM thus it changes all map textures models and entities alike, everything gets modified to benefit from this. Modifications are NOT made to the official pk4 files, instead a single pk4 named Z-tdm_materials_cubemap.pk4 is generated to override the old defs, you can revert at any time simply by removing this one file. The cubemaps are subtly blended in without using extra vertex / fragment shaders which should have minimal performance impact, they also respect the bump map of the material and are deformed by it... each cubemap is masked by the specular map which gives it a close feel to PBR, materials without a specularity texture are considered rough and remain unchanged. Simply download the script and use it in your TDM folder, you'll need either Linux or a bash environment on Windows (untested): material_cubemaps.sh #!/bin/bash # Add cubemap reflections to all TheDarkMod materials containing specular maps # Use sub(/\r$/,"") to fix DOS line termination, https://stackoverflow.com/questions/45772525/why-does-my-tool-output-overwrite-itself-and-how-do-i-fix-it # Unpack all materials mkdir "temp" for f in *.pk4; do unzip -o $f "materials/*" -d "temp" done mv "temp/materials" "temp/mtr" mkdir "temp/materials" cd "temp/mtr" # Inject cubemap code into all materials with specular maps, the reflection is masked by specular intensity # First ensure the file contains at least one definition that need to be modified to avoid needless repacking for f in *.mtr; do awk '{ sub(/\r$/,"") if($1 == "specularmap" && $2 != "_black" && $2 != "") exit !f }' "$f" if [ $? == 1 ]; then awk '{ sub(/\r$/,"") print $0 if($1 == "specularmap" && $2 != "_black" && $2 != "") { print "" print " // Cubemap reflection for specularity" print " {" print " maskcolor" print " map makealpha(" $2 ")" print " }" print " {" print " blend gl_dst_alpha, gl_one" print " maskalpha" print " cubeMap env/gen3" print " texgen reflect" print " }" } }' "$f" > "../materials/$f" fi done # Pack modified materials cd ".." zip -r "../Z-tdm_materials_cubemap.pk4" "materials" rm -r "../temp" At the moment I haven't done a full comparison and only tried it out on a map I'm working on: It's possible I might do my next TDM stream with this on which will allow others to see it better. From what I'm noticing it's pretty much perfect: Very subtle and doesn't disrupt visually, it does improve realism in a lot of cases as you move around and see the shine... given the texture is almost always masked and distorted by bump you don't feel the reflection is ugly and fake but it feels natural. Currently this is here as a mod for players that wish to use it... not gonna lie part of me is tempted to suggest it be considered for 2.11, it's definitely an improvement to having no reflections at all until a better method is found. Please try it out and share your own thoughts and images, below are a few screenshots I took during my first test to confirm it works as expected.

I really like what I see so far. I don't have the best test scene but I really like the "patch" entities as just a few of these sprinkled around add a nice sense of life to even a simple natural scene. I like being able to switch between the wind variants, but the default low wind variant is rather subtle and the strong is quite, well, strong. Animations are probably a pain but I could see if there was an option in the middle using it. Seems like the meshes don't have the skin variants defined? You can find a bunch in the general skin browser but nothing limited to the model itself. The larger patches look great, especially at a distance, but they don't hold up as well close up. Part of that is a given with billboard alpha, but iirc in the original test map the large tufts have a sort of dense ground cover that pops in at a very low distance, but this kind of fleshes out the tufts when you're standing right in the middle of them, which I imagine as a sneaky thief you're likely to be. I don't really see an issue with performance, but I am not pushing as many of these entities as something like the original scene might. Really cool work and I think these will be an awesome addition!

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

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.

Edit: Sorry man, had to correct step #1 as I forgot that water brushes always have to be converted into water entities.

I've been wanting to post this topic for many months now. It's a continuation to ideas I posted a while back, regarding my wish to create a total conversion for TDM, adding a cyberpunk theme alongside the original steampunk world. The reason for making a new thread is that I have a plan laid out by now, but will need help from the community with it. I wish to know how many people would be willing to help out, so that I may know whether I should start laying out the foundation of this project. I will explain exactly what I plan to do in the form of a FAQ below, so that I can easily cover every aspect. This is going to be long, so make sure you have some time before diving into it! If you want to go straight to the points about what I require and skip the rest, read the titles in red which cover the essential paragraphs. What is this all about?The idea is in part inspired by one of the favorite games in my childhood, DeusEx - The Conspiracy. I used to spend weeks playing through it every few months, drawn by its adventurous story and its dark yet appealing environments. Since the last few years, it's been a dream of mine to create a FOSS cyberpunk stealth game with RPG elements, that would be entirely unique (similarly to how TDM is unique from Thief) yet have the same feel and atmosphere I loved about it (once again like TDM has the same atmosphere as Thief). My earliest thoughts were on trying to achieve this in Xonotic, which is a GPL licensed arena-type shooter I've been a long time contributor to. Of course I eventually abandoned the idea... mostly given that Xonotic has no features for single-player mechanics, such as saving / loading or any kind of AI except bots treated as real players. Then more than two years ago, I finally discovered The Dark Mod. After playing it for some time, I quickly realized it's by far my best option to making such a project come true. Why The Dark Mod, instead of building the game from scratch? It was designed to be a steampunk stealth game after all!The first reason why I want to use TDM as a basis is that it already has every crucial mechanic I need, in terms of AI and interaction and world programming. It does of course lack a lot of the features I ultimately hope to include, although most are optional and I could attempt scripting them at a later stage... for now little to no game code chances would be required. The most significant features are the AI (very advanced and intelligent), carefully balanced gameplay plus other common ideas, as well as the mapping system with its intelligent area portals. It should also be considered that while I'm usually a competent contributor, I'm terrible when it comes to programming something from the ground up, so there's no other way this could happen as a FOSS project unless I hire an entire team. The project aims to be a stealth game that works the same way after all, so why not? To exemplify what I mean: You can open DarkRadiant and build a medieval town with a tavern, then add a guard patrolling the tavern with a bow and a sword. In the conversion, you'll be able to build a futuristic city with a club, and have a guard patrol that club with a knife and a rifle. In both cases, the AI will do exactly the same things with equally correct results: The guards take the same patrol routes, chase after the player the same way, vocally alert one another in the same fashion, and search rooms and hiding spots as efficiently once the player disappears from view. There is no "medieval patrol style" versus "futuristic patrol style", the choices and decisions are exactly the same! The only considerable difference will be the assets and animations and settings. The second reason is that I'm a fan of the idTech engines as well as gtkRadiant based editors. idTech 4 is in fact one of my favorite engines in the line, due to how intuitively it was designed at its core and how much it pulled off during its day. Its only problem is that it hasn't had as many developers forking and modernizing it, unlike idTech 3 with say Daemon engine (for Unvanquished)... that is of course not its fault, and in part due to being open-sourced much more recently in comparison. How exactly would the mod work? Are you thinking of creating your own TDM fork?I don't plan to create an actual fork of TDM, which would be impossible to maintain on my own and only divide the community and its efforts. My plan is to create a mod that will run on top of vanilla TDM, adding new content without affecting any of the existing functionality. The mod would be distributed as one or many pk4 files, which are simply dropped into the main directory next to the stock pk4's! Its assets will be grouped under the mod's own name, so that they're always distinguishable from the normal ones... just like every default component is listed in a "thedarkmod" directory inside DarkRadiant, they would be listed in a "howeverthiswillbecalled" group. Once you have the pk4(s) of the mod inside your TDM installation, normally download any mission using them it in order to play it! So missions will be able to use entities and assets from both stock TDM and this mod?My plan is to allow that, and nothing should prevent maps with mixed assets. Keep in mind however that I ultimately want the mod to be independent, and encourage relevant missions to only use textures and entities included with it rather than a mix! If you take out every single stock TDM asset (excluding md5anim's which will be reused) the mod will be expected to work on its own. Will the new assets also be non-commercial?Unlike vanilla TDM, I don't wish to include any CC-*-NC and CC-*-ND assets with the mod. That's primarily because I find them limiting, and feel that they ruin the openness of the project. Is there a name for the mod yet?I've been thinking about it but haven't fully decided so far. I want it to be something familiar and related to TDM; Initially I wanted to call it The Dark Modern, but that sounds rather silly. The name I'm considering now is The Dark Machina, which retains familiarity with TDM and is also more theme relevant... further suggestions are appreciated. What is the benefit for the community? Why should anyone put any effort into this?The project is targeted to everyone in the TDM community who alongside a steampunk stealth game, would enjoy a cyberpunk stealth game of equal or greater visual fidelity... with exactly the same base gameplay and core functionality, but an entirely different world and atmosphere. The project will be publicly available on a Git repository of its own (most likely Gitlab), and anyone will be able to easily install it on top of vanilla TDM. Simply put: If you help and things go according to plan, you'll have a triple-A scifi game inspired by the look and feel of the DeusEx series, just as you currently have a triple-A game victorian game inspired by the look and feel of Thief. What do you need help with exactly? What would others have to do?Obviously I'm not asking others to do the work for me. But at the same time, it's not something I can just go ahead and do on my own either! For this reason I've come up with a plan, which would allow contributions to happen gradually whenever someone willing to dedicate their time to helping adds something new. This is mainly a call to existing TDM developers, who know best how to export and define new assets. If the project takes off, based on the answers I get in this thread, the starter plan is as follows: I will be creating two Git repositories. One will be the official repository of the mod, which will contain assets in working format and condition... the other will contain images, sounds, blend files, and other resources in their native format. This will include freely licensed assets I find on the internet, which I will hand pick and tweak to make sure they're in the readiest state possible, then sort them in a way that's easy to work with. Most will be taken from http://opengameart.org and http://www.blendswap.com and I'll likely use a few things from Xonotic altogether! The assets included in this repository are to be exported and / or converted to TDM compatible formats, then included in the real mod repository. A list will be maintained in order to keep track of which assets have already been ported. Every ported asset can be issued as a pull request, or sent to me personally in case the contributor doesn't have access to the Git service that will be used. The rigging, exporting, and conversion processes are what I require the community's help with! As far as models textures and sounds go, no new content will need to be created... I plan to use freely licensed resources which are already available and plenty, enough to create a full mod out of. Obviously I'll be doing some of the exporting and definition writing myself, but since there will be so much new content I can't do it all on my own... unless I dedicate every waking hour of my life to it for over an year, which would be more than I can handle TLDR: I'll be compiling a repository of game-ready assets, such as textures and models and sounds. Anyone who wishes to help is only asked to pick them up, adjust the TDM specific necessities (exporting to md5, creating material definitions, etc) and publicize the results for inclusion. So no new content is going to be needed?For the most part, no. There is only one exception to this rule: Voices. As they're something TDM specific, they have to be created to match the world and what's happening in it. They are however not a priority, and can happen at a later stage in the project. Until then we can live with a few cyborg troops saying things like "in the name of the Lord Builder, you shall go to the gallows, you heretic" Other than that, I will eventually want to add new functionality. Including a Minecraft type inventory system, computer chips the player can install into their suit or body in order to gain enhancements (modules / augmentations / whatever), and most importantly a re-implementation of the interactive touchscreens in Doom 3. Those are however even more distant needs in comparison, and not what this thread will focus on at this point... I plan to look into such once I'm sure there are enough contributors to be certain this is happening altogether. What do you need done for each type of asset explicitly?Here is a list of every new asset type the mod is going to introduce, and the steps I estimate to be required for each: Characters: I will be offering the blend files of all characters scheduled for inclusion. They will contain the mesh, textures, as well as the rig that the character comes with (if available). Steps to be taken include: Rigging the character to the TDM animation skeleton after using the original rig for initial posing (including face rigging), generating the shadow mesh, making sure polygon count is within acceptable limits, and finally exporting to md5. Lastly, generating and tweaking the character definitions (stats, team, social status, voice, etc) and the material definitions for the character's textures, which should be all that's needed for the model to become a working character. Notice: I'll be preparing a blend file containing the simplified / optimized TDM rig in order to ease the process, including the face rig which I remember had to be extracted from existing characters. Models: A similar process would be needed with static models and simple entities: They will be distributed as blend files which include the model and texture, and need to be exported to ase / lwo, with entity and material definitions in place. Textures: Most will likely be distributed as jpg and png, and will need to be converted to dds and tga. The material definitions will need to be created as usual. Sounds: Will be distributed as wav or ogg, which normally don't need to be converted. Sound definitions need to be created however.As far as specific TDM functions go, this is how I intend the modifications to work per component: Weapons: The plan is to keep each weapon the same in terms of purpose and functionality, and mainly modify the models animations and sounds. The same core code will therefore be used by each, but new entity definitions should be made in order to not affect maps using the existing items while the mod is installed. Menu: When a mission intended for the mod is installed, the main menu will use different textures and a different background song... no modifications to the entries or functionality will be made otherwise. I'm uncertain as to how this can be achieved, although it is lower on the priority list.What will be the modern equivalent of existing TDM items, as well as new content?Like I said, I plan to keep the functionality and purpose roughly the same, at least for a while. Therefore items will serve the same goals, and work almost exactly like the existing ones in TDM... it will be basically the names and appearances that change. The important replacements I currently have planned include: Weapons: Blackjack becomes Police Baton or Taser. Sword becomes Knife. Bow becomes Crossbow or Sniper (arrow types and behaviors unchanged). Items: Lantern becomes Flashlight or Keychain Light. Telescope becomes Binoculars. Compass remains Compass. Snake and Triangle lockpicks become Physical and Electronic lockpick (mechanical doors are unlocked with the first, electronic doors with the later). Potions become Medkits, Syringes, or special types of enhancements.As far as completely new content goes in regard to items and entities, here is a rough list so far: Books & Notes: Alongside the existing books and notes, laptops / smartphones / tablets will be added. They are unrelated to future plans for interactive screens, and simply refer to new types of visuals for readable items found throughout the world. Lighting: The replacement to existing candles and torches will mostly consist of desk lamps, particularly neon and LED based ones. Characters: A similar structure of factions will be followed, compared to the existing guards + thieves + civilians + beggars + nobles. In this case the main categories will be: Police (ideally different suits for various units), gang members (once again different clothing for each gang), with modern looking civilians of various classes. There will also be entirely new outfits covering jobs existent in modern times, such as scientists or industrial workers. Robots: The existing code behind the Steambot will be used to implement multiple kinds of security drones patrolling an area. Especially in early stages before new scripts are considered, they can have the same function of only sounding an alarm when the enemy is spotted. Props: There will be various modern props added throughout the world, depending on what content I find. This will include: Flaming barrels for poorer areas, futuristic cars and bikes parked on the sidewalks, televisions that play videos (in case itTech 4 allows video textures), and the list goes on.Closing thoughts:First of all, thank you for reading this enormous post, regardless of whether you wish to support the project or not. This is something I've dreamed of creating for a while now, and I really hope at least a few artists out there are willing to support it! Please leave your thoughts if you want, as well as voting on the pool so I can more easily estimate the help I may expect.

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

DarkRadiant 3.0.0 is ready for download. It took a while, but DarkRadiant 3.0.0 is finally available. Most of the time has been spent on improving DarkRadiant's renderer, which now features shadow mapping support of up to 6 lights. It's still not matching the engine's output (especially in terms of performance), but it should be faster and much more helpful than it was before. The effort that has been put into the renderer rewrite plus the bigger changes in the previous few releases make the jump to the next major version feel more than justified. Besides of that, a lot of non-renderer issues have been resolved in this release too, next to some fine usability improvements. For more things that have changed or fixed, see the list below. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.0.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! And I'll gladly repeat myself, by thanking all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.14.0 Feature: Realtime shadow mode Feature: Allow way to hide some entities in Create Entity list Feature: MD5 Animation Viewer: show current frame & total frames Feature: MD5 Animation Viewer: jump to frame Feature: DarkRadiant warns about missing .darkradiant file on load Feature: Ability to center 3D camera on selected entity Feature: Cut functionality to complement copy and paste Feature: Save user settings by application version Fixed: Free Rotation not working anymore, can only rotate along 3 axes Fixed: DR crash with combination of mouse buttons pressed Fixed: Git Sync Exception: too many redirects or authentication replays Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Fixed: Selected Skin not showing in ModelSelector Fixed: Reload Defs takes longer every time Fixed: ForceShadows materials are not casting shadows Fixed: Objective GUI doesn't display properly in some places Fixed: Crash on loading certain maps Fixed: Vertex colours do not show on models in lighting mode Fixed: Entity inspector shows inherited spawnargs of previous selection Fixed: DR overwrite order for defs is different from TDM's Fixed: X/Y and Camera View bindings don't save properly Fixed: Material Preview rendering Fixed: "Replace Selection with exported Model" sets classname to "func_static". Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant Fixed: Rotating a func_static result to random stretch textures Fixed: DR crashes when syncing with remote Git repository Fixed: Switching visibility of Github repo from public to private causes crash Fixed: Dockable window layout doesn't save new floating XY views Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg Fixed: Entity inspector considers inherited colors black Fixed: ReloadDefs moves def_attached light crystals to entity origin Fixed: Option to filter skins out of search results in the Choose Model dialogue Fixed: .lin files can't be opened if different case than .map name Fixed: Model chooser radio box selection issue Fixed: Changing multiple lights between omni/projected resets colours to black Improvement: Allow absolute paths for snapshots Improvement: Light diamonds and Speaker radii are transparent Improvement: Unify Declaration Parsers Improvement: Add "Create Particle" to right-click orthoview drop-down menu Improvement: Revisit Interaction Shader to get closer to the TDM looks Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs Improvement: UI for worldspawn-to-entity conversion Improvement: classname field should always be read-only, to force use of the "Choose entity class" button Coding: Update solution and build dependencies to Visual Studio 2022 The list of changes can be found on the our bugtracker changelog. Have fun mapping!

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

Hey Everyone, I recently reformatted and I'm getting DR back up and running. I'm having a slightly annoying problem with the entity class folder structure not being collapsed when I search for entities. I vaguely remember fixing this some how by unpacking my .pk4s? However if I unpack them and delete the original pk4s, nothing shows up in DR. Maybe its something obvious I'm just overlooking...