MirceaKitsune

Oh, their assets are likely still proprietary: Technically even the old Doom 1 & 2 from the MS-DOS era are still copyrighted, although you'll find those on abandonware sites since realistically no one will complain about "pirating" the original Doom game in 2024 Only the engines were open-sourced per say. What I'm looking for are repositories of idTech 4 ready assets that are freely licensed. People made mods for things other than TDM, including vanilla Doom 3 or Quake 4 which TDM itself started out as. I think there were a few other projects based on the Q4 engine otherwise, though other than TDM I'm not aware of any major ones, just an experiment with an engine fork I've seen shared on the TDM Discord server.

Was thinking how as an alternative it's easy to build a bash or Python script to do it. The hardest part is scanning the map to figure out every resource used: Recursion is needed since a map may use an entity that has a model which uses a skin that itself uses a material and that material uses a bunch of texture images. In the meantime it's possible to do it all manually if you really want. As long as you're careful to not miss any packages and test your standalone distribution to make sure the console isn't reporting any missing data errors. A special mode for the TDM installer / updater could also work as an alternative, allowing you to install TDM with a particular FM and only the required core packages for running that FM: This would be an equally nice solution, as it would allow a FM creator to still distribute an executable for their FM which then installs itself similar to how a MMORPG or Minecraft self-update. And the engine has licensing limitations for hosting on platforms like itch.io? The code is GPL and most assets are CC-BY-SA-NC, so if you aren't selling it and post the project for free it should be good? I remember us having issues with Steam that didn't allow TDM to be hosted on it, but those were due to its ridiculously strict licensing terms.

Same, that's what I'm thinking: For simple standard FM's sticking to the mission download menu and this forum is ideal. My idea is for special projects, which are large and unique enough to be like standalone games and have their own project page on a game site; Even in their case they should definitely be in the mission downloader for TDM users to install normally, but can also be distributed in a place like itch.io for the non-TDM audience. It would also be fairly simple to implement: DarkRadiant already knows which resources a map is accessing, be it entity defs / models / skins / materials / textures / sounds: It just needs to extract those files from their pk4 and copy them to an install directory, followed by all core assets used universally like menu / player / etc, then just blend in the FM directory and set currentfm.txt to the project.

There is a simple but effective detail that could make TDM feel even more complete, which somehow was missed to this day; I think we should have HUD sounds for selecting tools, something unique for each vanilla item with the spawnarg available for mappers to set on custom items. Arrows have one for being selected or holstered but not items: I'm sure we can find what we need on FreeSound or OpenGameArt, if it helps I can dig for the best ones and look for something that feels satisfying to hear often. Examples: A wire sound when switching to the lockpick, a squeaky oil lamp noise when switching to the lantern, a bottle splashing when switching to the health potion. In addition the lantern needs sounds for being turned on and off, for now even using the candle sounds for lighting and extinguishing may be an improvement to the complete silence. Same for the spyglass, you should hear something as you activate and deactivate it. Let me know if there's other items lacking audio that I missed: Lockpicks for instance don't need it as the door manages the lockpicking sounds including an unique sound when you start picking. Lastly I think a simple animation for selecting and deselecting items should be included, which should be easy to do in the GUI definition. Right now the icon changes abruptly: I feel there should be a slight transition effect for fading / scaling / sliding the icon, which should be used on the weapon icon too when switching between the blackjack / sword / arrows.

Not sure if related but: My dream with creating a multi city hub FM was to allow the player to travel to different countries by ship. Part of the plan was having a few readables written in relevant languages, granted I can use Google Translate to obtain a few sentences in an Asian or Arabic or other language. Problem is that last I checked, readables only allowed english characters, everything else will appear as a rectangle: Most fonts don't even support symbols like French or Romanian characters (eg: ăâîțș). Too much work would likely be needed to patch the existing fonts, but maybe we can find and include a font set designed explicitly for those languages that special characters in readables can fall back to?

My take on this, at least as far as what I feel vanilla TDM could do: Offer an option in the main menu to see the name of every held object that has the "name" spawnarg set. Currently this is only done for bodies, if you pick up a dead or unconscious person you'll see their name at the bottom of the screen... for players that want this I'd support the ability of displaying it for anything else. Not sure how many of the default movables set it though. Like if every movable chair definition has "name Chair" configured. But that should be easy to solve in an update even if not, we just did subtitles for all AI barks so

I believe that many months if not years ago, I made a discussion on the limitations of the current weapon system. We're still using the old weapon slots defined by the engine and limited to 16 guns, when it would be much more flexible and ideal to define the blackjack / sword / arrows as items so FM's can add unique ones. This is unlikely to change anytime soon, but even with the in-engine definitions I think there's room for improvement. Firstly the player script should probably use all 16 slots and point them to an entity which can be null by default. That way FM's that add custom arrows won't need to override the entire player definition, just the unused slot TDM makes available. I created a custom flash arrow a while ago which I'd like to use in my FM's... been begging the team to take a look at it since I think it can be included into vanilla, but since that hasn't happened yet an easier way to include it myself would be most welcome. As for the default arrows I think they should be easy to override, of course the question is how. Custom vars seem necessary to do it right; As a general rule I don't think defining them should be forbidden since even map scripts might introduce custom settings you want to be able to define. I also agree with allowing weapon balance to be customized through settings, like the time it takes to charge the bow and how fast the arrow is sent flying and the cooldown after that and so on.

As someone focused on attempting special FM's with slightly unique stories and genres compared to most missions, especially when it comes to adding a blend of scifi to the mix, I could use a repository of readily available custom assets that deviate from the default theme. Obviously I can grab anything from OpenGameArt or BlendSwap, but for a lot of stuff converting models or creating materials might be a lot of extra work better spend actually getting a map done. I know there were a lot of mods for Doom 3 / Quake 4, which makes me wonder if any freely licensed ones were ever released: Almost everything made for vanilla idTech 4 should be compatible with TDM and possible to copy-paste into a FM, especially when it comes to decorative models or textures or sounds, they should be plug-and-play from any Doom based project: I'd only need to know they're freely licensed and at worst CC-BY-SA-NC like TDM. Only exception is AI: We use our own rig and animations, any custom character must have been made for TDM. Though when it comes to monsters, granted they have their own animations and IK for ragdolls included, I suspect any md5mesh can be easily adapted with a custom def based on the spider AI: Technically even humanoids might work since I don't think we're limited to a hardcoded rig... we do however have a lot of specific animations for those so any complex character would need anims for walking / attacking / using / more which can be remapped, things like firing the bow would be impossible as that must be precisely animated yet a generic swing might work for any melee weapon. I'd also ask if anyone's ever made custom AI that were never featured in any FM but are available for others to use, like the anthro characters I rigged ages ago but never got around to actually making a FM with. Only resource I can think of myself is the PhilipK texture set, one of the most popular texture packs for open-source projects: The pk01 and pk02 packages come with material definitions for Quake 4 builtin, they can be extracted and used directly in any FM... I think I already did that during my attempt to create a Cyberpunk mod and the materials work great in TDM.

Although aspects like the non-commercial license make this a bit different from an actual engine like Godot, I've always thought of TDM as a sort of no-code game engine for making single-player games, be it one centered around a fixed genre and default assets. Even if FM's can't be sold, I still pondered the idea of distributing special projects as standalone packages, which should of course be done in addition to having your FM in the installer which remains the ideal way to run them. As such I was wondering what others think about a procedure to pack your map with the TDM executable and relevant assets as a zip archive, which can then be posted in places where anyone can easily download it and run the exe. The idea is aimed at making distribution on platforms like itch.io / GoG / Steam easier: If you make an involved project based on TDM that you want to offer on your own website or service external to the normal TDM community, it's harder to tell your players "go to thedarkmod.com download and install the project TheDarkMod then look for the name My Fancy Mission in the mission installer to play this"; Folks these days will find that a bit convoluted, everyone is used to downloading a zip or an installer and running it in place. FM creators could have more reach by being able to share downloadable FM's elsewhere on the internet, even attract new players to TheDarkMod who wouldn't normally look into it but discover TDM from this one FM they saw on a blog. A good example is the RenPy visual novel engine: You can run a story with the engine in place, but if you want to distribute it you can do so with a copy of the engine embedded for all platforms. Without this ability RenPy users could still make novels with the engine, but would be limited to the RenPy community and people already running and familiar with it as a software: It would be hard to distribute it to people in other places who don't necessarily know what RenPy is and might not play it if they have to install the engine separately then plug your novel into it. How such a thing would probably be implemented: A menu called Distribute Standalone Package would be available in DarkRadiant. It checks which assets are used by the active map, for campaigns scan every map in the maps directory; Those assets are extracted from the core pk4's and copied to an install directory alongside core assets / game code / engine executables with the active FM set to your project. For example: If you use it on a test map that only has the dirt material and a citywatch AI, the install will contain a copy of the dirt material / texture and the citywatch models / textures / skins / defs / vocal sets followed by core stuff and of course the map itself.

Thank you, that sounds amazing! If it works well and fits in I presume we may see this make it into vanilla? Feel free to share a video in the meantime, curious to see it in action

I've actually thought of this exact thing as well! It would be both easier to manage and equally interesting as a mechanic. Very easy concept to implement too: Just add a stim that temporarily changes the light's sound shader for a few seconds before reverting back to normal one, give lights an s_shader_wet spawnarg and include a low volume flickering noise... it should make guards a little suspicious but less than the noise arrow in this case. Just remembered this was in fact a plan for my flash arrow, a custom weapon I've been asking to get included in vanilla but so far it's been forgotten. I believe the last version only blinds guards using the flash bomb effect, but one of the goals was to have lights temporarily turn off or flicker before coming back on after a few seconds, though this would require a custom script at best.

Hmmm. I still like my idea of shooting broadhead arrows at fragile lights to turn them off, but I like your idea as well! It's not like we couldn't use a new item, and it's something mappers would have control of by only placing it on levels where we want to have this behavior. But then we'll have to make all lights frobable by default so even this approach would be a little complicated.

Thanks for those fixes! They didn't affect me and any FM's I've been working on, but I'm happy to see a solution was found and you could help those affected so quickly. I like the idea of being able to customize arrow behaviors from cvars! Most open-source FPS's (eg: Red Eclipse) offer the ability to set weapon behaviors with custom configs and create your own unique balance. While I agree it's good to not have a ton of settings, I think the weapon slots should be customizable this way... at least for now as we remain stuck with the old in-engine weapon system and can't turn the blackjack / sword / arrows into items like everything else.

Part of my point was that breakable electric lights could have an interesting contrast: They'd attract attention while also making it harder for you to get caught. When broken they should create a loud popping noise that makes nearby AI walk to them and investigate the disturbance, if they see the broken lamp even draw their swords and do an alert search... however once they've calmed down and moved on, you're rewarded with the ability to sneak there without being seen. The player will have one of two typical strategies: Either wait until there's no guards nearby in order to shoot a lamp, or shoot such lights if it's better to have guards searching but not able to see you compared to the guards being calm but able to spot you in bright light. Mappers would themselves place those lamps in areas where they want to create this particular challenge.

I understand some changes that break backwards compatibility, long as they're kept minimal and hopefully don't render old FM's unplayable unless patched. We should keep in mind some maps may never get updated, especially ones who's authors might no longer be around... at the same time some things can't be easily improved because keeping it backwards compatible is more challenging, I felt a few things were limited for that reason a couple of times.

Oh, some implementations might work a little differently from what I remember the term megatexture referring to. From what I used to know, it meant turning the entire level into a single model or set that uses a single enormous texture. While the concept may have its upsides, there are two major issues that negate any benefit in my view: The first is system resources, you don't benefit from any reuse as every pixel is unique, the only way to do it at scale is with a gigantic image thus a huge performance drop in pretty much every department. The second issue is that level design becomes far harder and more specialized... while here in TDM we only need to draw a bunch of brushes and place some modules to make a level, an engine based on megatextures would require level designers to sculpt and paint the entire world in software like Blender which is far more difficult and we likely wouldn't have even half of the FM creators we do today, even for those that know how to do it imagine the task of manually painting every brick on every home and so on.

Megatextures were a horrible idea for obvious reasons, not sure why ID chose to learn that the hard way. The concept from what I remember is the whole map uses a single gigantic texture... instead of how we independently pick a couple of 1024 px brick materials for a few brushes and surfaces, the whole map acts as one model with one material and a single texture which probably needs to be 1 million x 1 million pixels even for a small level. This is ridiculous from a perspective of system resources with 100's of GB's of storage and huge (v)RAM requirements and hours of loading time, as well as raising the skills required for level editing since you now need mappers to also be texture artists and sculpt / paint their levels instead of just placing stuff. The only thinkable benefit is there's no repetition since every pixel on every part of the world is unique, but who notices any similarity with independent texturing if it's done right anyway? Detail textures have yet another advantage there: Since you scale the pattern independently on top of the original texture, you can make every surface appear as if it has unique pixels like megatextures. Hence why I'd advice having the details be very high-res, 4k or 8k even 16k if we can take it: Yes that's enormous, but remember we'd only have a few patterns probably no more than 15 in total, and can store them as grayscale then use a single image to modify both albedo / specular / normal (heightmap to normalmap): Map the detail in world space rather than the brush or model UV map, and the resulting pattern on every surface in the world will always be unique since the original and detail textures will be out of sync.

Obviously the change will only work in last night's dev snapshot and onward. But missions can already start implementing this: It's just that older TDM versions won't see the debrief screen and only future players or dev users will enjoy them.

@The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.

Thank you for the lovely change! I wonder if anyone can let FM authors know about it: I think this is a great opportunity to update old FM's if their authors are still around and willing to... if anyone does maybe drop a mention here, I'll be happy to replay them for this addition alone.

Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

It could also be that on Linux we have to compile DarkRadiant ourselves, which means it's being compiled against newer versions of packages (GTK, WxWidgets, etc) and a slightly different configuration overall.

Looks great, thank you! That looks even better: It's where DeusEx had its player status screen, feels even more like TDM with DX characteristics now I think I placed it above the light gem as that's where player info was technically being stored, with the new subtitles covering that position the move is a great decision. By the way: If anyone wishes to continue and improve this mod, I'd appreciate seeing your remixes of it. I had it mostly finished last time on my end; I think the main issue was upgrades require items to be placed on maps, augmentations may not work on every FM without a way for them to automatically spawn in random places... my imagined solution was to also offer upgrades based on loot gathered or other achievements but I never got around to adding that.

I also take it the skin editor isn't among the most used parts of DarkRadiant, making this less easy to spot. Hopefully now the team will notice the issue, and it's ideally nothing hard to fix since DR has a history of GUI issues like this that stabilized.