Search the Community

Is that really correct? Unless TDM team changed stuff from Doom 3 times, if you use Doom 3 as example, normal maps that represent outward surfaces, use OpenGL system, those that represent inward surfaces, aka holes, use D3D system. On real DirectX renders, outward surfaces, use the D3D system instead and the OGL one for inward, is inverted. And to reinforce this the original example by idSoftware, looks to use the OpenGL system see here cyan for top, purple for the bottom, in d3d is inverted. Thou like I said maybe the TDM team changed all of this by now...

I think it would be smart to go ahead and start a "Newbie thread" that covers all newbie questions in one place, as with the TDS Forum. It doesn't have to be this one, just for future reference. Aaanyway, I was going through the A-Z Tutorial, and right about the time you make the pool of water, I fixed some leaks, thought I got them all. Now it won't Dmap again, but when I hit Pointfile, it says "Could not open pointfile: E:/games/ ... /TutorialMap.lin" I don't know why since it's been working up to now. So if I have a leak I can't find it, but it's troubling just that Pointfile suddenly, inexplicably doesn't open! There isn't any ".lin" file either; not sure what happened to it. Any ideas? Edit: I started a map from scratch and Pointfile didn't show up again. So whatever it is, it isn't something I messed up in that first map, but a general problem I'm having with DR. Edit2: But it does Dmap and Map just fine, so that's ok.

So, that's how it was explained to me. Even though it seems counter intuitive, using Direct X maps has worked for me. I was recently trying to import a bunch of textures from Polyhaven.com (they offer both OpenGL and directX normalmaps) and I used the OpenGL version at first, but when I put it in-game there was an inverted green channel. I then used the directX version and the normalmap worked just fine I'm happy to be corrected on any of this though. Maybe Polyhaven does something different with their normals, or I'm doing something wrong

That's a very valid question. Personally, I'd say the key is to watch what the otherwise-disengaged fringes of the community are saying. If first time posters or long time lurkers start coming out of the woodwork about well made new missions, praising them for their geometry and story but saying that innovative parts of the gameplay felt frustrating or off, that's probably the first sign that the innovations are starting to get out of hand. For a more concrete example, re-read the comments on Hazard Pay. As much as I and many others love that mission, it's clearly a case where the author strayed further than many people were comfortable with. It also points to the likely endgame if authors do take their customization too far. After getting the negative feedback, kingsal made adjustments, and now the mission is much more friendly towards player preferences that don't match the author's original vision. You don't need to restrict the mapmakers' tools to stop them from straying too far from the traditional formula. When people start speaking up, the authors will rein themselves in on their own.

I think this is a slippery slope fallacy. Just because the ability to customize exists does not mean most mappers will use it. On the contrary, if one considers the customization that are already available, we see that the overwhelming majority of mappers stick to the defaults. The exceptions are interesting also. Kingsal's the only mapper that readily comes to mind who habitually deviates from presets seemingly just for the sake of being different. However everything they make is clearly in service of cohesive visions. Hazard Pay, no matter how you feel about it, unarguably loses a great deal of its survival horror character if you take away the napalm arrows or the punishing save system. The Voltas don't need to use Thief style elemental crystals in place of TDMs arrow model, but the fact that they are there makes a definite statement about the author's awareness of their inspiration for their work in TDM from the original games, which in turn draws attention to other, subtler creative choices. I think it's also telling that some of kingsal's modifications have been adopted by other authors. As OrbWeaver said, "If the defaults are widely disliked, they should be changed." However, how can the community come to a consensus unless there are maps to showcase the advantages of new innovations? Requesting, or worse requiring, players to go in and manually change settings in order to experience a new mechanic is never going to gain any traction. Certainly it is not worth the effort of creating an entire map built around a new paradigm.

Welp it's about that time again to wheel out The Lieutenant for another mission and I could use some help making sure it's at least somewhat playable. Please register your interest here and I'll start a new beta testing thread soon. Due to custom assets the file size is quite large (about 500 MB). Potato users welcome. Some screenshots:

As you probably know, overriding core files which are not specifically designed for that is fragile and unsupported. Indeed, it usually works... until it does not Here is the list of missions which completely override tdm_weapon_arrow.script: ahouseoflockedsecrets @Moonbo byanyothername @joebarnin cauldron_v2_2 @kingsal good @Amadeus hazard @kingsal northdale1 @Goldwell northdale2 @Goldwell seeking @Amadeus@Dragofer@Wellingtoncrab snowed_inn @Goldwell @kingsal written @Amadeus @Dragofer I have just got rid of creating cvars dynamically (5600), and shooting the bow stopped working in these missions. Because they distribute an old version of the script which runs in "debug mode" that relies on dynamic cvars. Core version was updated some time ago and this debug mode was removed. I'd like to ask authors: why did you decide to override this script? Perhaps we can add some customization points and delete overrides?

Speaking of actions for the missions which only tweak zoom delay. What would you prefer right now? Mission broken on the latest dev build (as it is now), but working as intended in the latest release. Mission working as intended on the latest dev build, but working without customization on the latest release.

I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others. Background As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling. Current Font Findings 12-pt Size for All Fonts Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage. For Fonts Used in Main Menus, HUD, or Subtitles The numbers shown approximate the number of "characters needing work" Fontname Size-24 Size-48 carleton 20 16 carleton_condensed 20 35 mason -- 33 Since 24 pt is not distributed, engine uses 48 pt. stone 30 83 For Additional Fonts Used in FM Readables, Etc. Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters. Further details are here:

Sounds great. Unfortunately you don't have to get very far in any discussion about either changing existing gameplay mechanics or about giving players more in game customization options to see why mappers stop bothering with the debate club politics and instead divert the energy to do what they can to address what issues they can themselves. There is clearly also a disconnect between how people think they feel about these changes and how they do in practice. Kingsal's missions seem to be widely considered as some of the most polished missions in the game, because they are a holistic designs that look, sound and play a certain way. As a result I have never seen a player complain about something like the run modifier being increased in a particular missions thread and it’s clear there are very few players who are ultimately conscious of anything besides that the overall experience feels good. So there is reason these get adopted by other authors. The players are entitled to their opinion - but it's the mission authors choice ultimately. And I can only speak for myself, but I came to TDM because I saw working examples of things I wanted in my mission. These were not “stock” or “standard”. They were achievable by virtue of the games extendability. If the day comes where we get locked out of that kind of control of our designs, I would probably walk.

On https://wiki.thedarkmod.com/ I see the "log in" link, but I cannot find a "create account" link, or any description on how to create an account, or who/where to ask for one.

For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts

Well that doesn't mean that everyone is d'accord with all the gameplay choices he made in these missions, does it? All I can say is that I never got the impression here or elsewhere that there are issues with the weapon behavior in TDM. Maybe apart from the blackjacking, which has been a controversial topic in the past. I can only repeat myself in arguing that the big problem is the uniformity of essential gameplay elements. The game just doesn't feel coherent, if every FM author changes important gameplay dynamics, and it makes it difficult and frustrating, not just for beginners.

Hey @stgatilov, sorry for the late reply. In looking at the tdm_weapon_arrow.script in A House of Locked Secrets, there is a comment line that says "Adjusted to stop the raising and lowering animations during a realm transition." From what I remember, when the player was switching between the physical and spiritual realms, if the player was holding a bow the lowering animation would play upon starting the switch and the raising would play after it. And so we modified the script to disable those animations during a realm switch. That was the only adjustment that should be present. I think if you look for the line "if($info_player_realm.getKey("transiting") == "0")" it should be quick to spot where those checks were made. Thanks! -Gelo

I hope you didn't forget the (controversial) discussion about his implementation of a Resident Evil style save room in Hazard Pay. Or the change to the arrows, which one head shot zombies. These changes are anything but commonly accepted and wanted. Rather something he implemented, because he thought it was a good idea. Which is fair enough, but, it unfortunately leads to the lack of uniformity that I was talking about, when every FM author thinks he has to reinvent the wheel. Especially new players can't get used to how the game, weapons and enemies behave, if the behavior is different in every FM.

Well, I actually found that initial folder in the HiRes SVN repo. This is different from the TDM assets repo as it has a bunch of source files for textures, fonts, etc, but they aren't really game-ready assets. This is where I found the tga image files for the fonts I thought you were looking for. I haven't uploaded Tels folder yet, but I was thinking of uploading them in the HiRes SVN repo, just for the sake of backing it up

I agree entirely. Unless a mission is aiming to present a completely different gameplay experience (like making a rapid-fire archery-based combat mission instead of a stealth mission), I see no reason why things like bow aiming should vary on a mission-by-mission basis. If the defaults are widely disliked, they should be changed. If they are a matter of taste and there is no agreement on what the value should be, they should be configurable by the player and take effect in all missions. Imagine if every desktop application made its own tweaks to your keyboard layout or mouse acceleration because the author didn't personally approve of the default values. It would be a horrible user experience. Some applications actually do this with fonts, and yes, it's horrible. Potentially useful functionality made inaccessible because the author decided to ignore system font choices and DPI, and impose his hand-picked non-scalable 10pt font which I can barely read.

As a player, one thing I'm also not too fond of is the lack of uniformity. I think mission authors should take into account that especially players new to the mod want to figure out how the weapons work, and, they will have a hard time doing so, if many missions tweak the weapons. Apart from the "WTF" moment, they will also not know what the default behavior of the weapon is. Also not a fan of some other things some missions introduce, like the different sounds for foot steps etc. Most of them don't improve anything over the default sounds, to be honest. They're rather worse, and irritate me every time I play a mission with custom sounds.

Do you disagree with the core defaults in general or is this a character-specific setup for your mission? Or is it a test or...? ---------------------------------------------- Sometimes we must take things to the extreme to see the whole picture. Let's pretend all these years mappers have been tweaking the player slightly and depending on the mission: You walk faster or slower. You jump very high or you barely get off the ground. You jump long or fall short. You can mantle high or low. You make more noise or less. The lightgem is more sensitive or less. You inflict or take more damage or less. ... Any thoughts from anyone about this scenario? I wonder how the playerbase would feel. My opinion is that the above tweaks are justified when a different universe is competently established. Or when a new, fully realized character is introduced. Otherwise we are tweaking simply because we can, nothing to do with the story.

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.

Well, I disagree. I play this game for the features it offers, not the features some mission author thinks he has to change to his personal favor. And, frankly, some of the more current missions offer too much of that "I think this works better" feature change. For example, the sounds some missions introduce add nothing over the original sounds, but are rather worse in my opinion.

"May his iron mold the current as we were molded. May his instrument expel all obstruction as we are his instruments." - Collected Sermons of Master Plumber Roto Rooter Few would dare cross the Bridgeport Plumber's Guild. Fewer still could glimpse their secrets and live. CC0 POLYHAVEN PLUMBER PACK BETA Includes: Fully modular pipe kit with optimized shadow mesh, two skin variations and near perfect grid snapping at grid level 4 Moveable plunger prop which is fully compatible with the AI weapon system Worry free CC0 license All credit to the great polyhaven.com for the original mid poly meshes - consider supporting them on patreon. I just decimated and then rebaked the assets as well as converted the maps from pbr and made the additional model and material variations.

I can only speak for myself, but I think option 2 would be fine. This will at least allow the missions to be playable on the dev builds for now, and we can see if any other issues pop up

Again, that's not the point, The point is that the game is all over the place, if every mission feels and plays different. If you want that, hey. But, in my opinion, that's a big mistake.