Search the Community

My new mission, A Night in Altham, is available. We are already up to version 2! @Dave the Tafferfound an problem that deserves a fix, so here is version 2: https://www.dropbox.com/scl/fi/y4r1dmziuq6clh2im3qz1/altham2.pk4?rlkey=m3cv5v6v70lxbc9xha61nuxoj&dl=1. I will ask @nbohr1more to update the databases. Thanks to JackFarmer (alpha testing and custom ambient music) and the many beta testers (jaxa, Shadow, wesp5, Cambridge Spy, thebigh, datiswous, Mezla, MirceaKitsune, Melchior, Acolytesix, TheUnbeholden, prjames, Bergante). Thanks to @peter_spy for his beautiful Builder Compound assets. This is a large mission, so be ready to take some time. I recommend that you do named saves occasionally (I actually implemented auto-saves for this mission, but it was causing crashes on Linux, so I removed it). This mission has a lot of keys, so it implements a key management mechanism. Keys are removed from the game when no longer needed. This includes when you use a key to open a door, or if you pick a door/lock that also uses a key. Most keys are automatically removed, but there are a couple that aren't (for example, if they open up more than one door). In a certain area, this mission uses the Keyhole Peek feature of TDM. Typically, this is when you lean forward (F key) into a door keyhole and you can see into the next room. But in this case you don't lean into a keyhole. It's a hole of another kind. It's an unconventional use of something that isn't used a lot in TDM; hopefully the mission context will make it clear when to use it. The mission does not use Keyhole Peek for regular doors. Be aware, there is a known problem on Linux, where the peek feature can cause a crash. Peeking is not required for mission completion. This has been tested on TDM 2.11a and the current dev build of 2.12 (dev16854-10518). Scary things warning: Difficulty settings make a difference. Things that are affected by the difficulty level: Enjoy!

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:

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:

I most agree this is very confusing. The main light on my example, was not coming from the top but from the side and it looks correct to me, but your OGL example does look incorrect, if the light source is on the top right corner, so call me confused. edit: I made more testing, I was totally wrong and Wellingtoncrab is correct, it IS the D3D system, purple on the top for bumps, is the correct color, cyan in the top should be for holes. So my example is misleading and not correct.

In pursuit of a long-sought secret, the key to life everlasting lies deep within the recesses of an ancient athenaeum. Dragofer, Bikerdude, and I proudly present our FM for the Christmas Connections Contest titled "Written in Stone." Notes - TDM 2.10 Beta 5 or later is REQUIRED to play this mission. However, it is recommended to play using 2.10 Beta 6. You can get the latest version here. - This FM is a sequel to The Elixir. While it is not vital to play that before playing Written in Stone, there are some story connections. - This FM may be more hardware intensive than normal. LOD settings can be set below "Normal" to improve performance on low-end machines by disabling certain features. - Various areas will look better with shadow maps enabled at the possible expense of performance. - This FM implements the func_peek mechanic, allowing players to peek through any door that has a keyhole on it by leaning forward. PLEASE NOTE: This function has been known to cause crashes for a small number of players in the past, likely due to using the 32-bit version of TDM. At no point in this mission is it required to use the func_peek mechanic; it is purely optional, so feel free not to use it. As an entry in the 2.10 Christmas Connections Contest, the new features and assets used by this FM are: Download Version 1.1 This FM is available for download here: Google Drive OneDrive Simply place the written.pk4 into your darkmod/fms folder and you're ready to go! Promotional Screenshots Credits A big thanks goes out to Wellingtoncrab for making a beautiful city map, Narrator for their wonderful voice work, nbohr1more for creating the original story premise as well as a few readables, Goldwell for animating the introduction to our briefing video and Duzenko for making certain glasses work as well as they do! A huge thank you also goes out to our beta testers: Goldwell, Wellingtoncrab, Kingsal, noodles, Krilmar, Garrett(Monolyth-42) ate0ate, and Mike_A. Thank you all very much for your keen eye to detail and great insights! Asset Credits Kingsal's Killer Assets Wellingtoncrab's Wonderful Furniture and Book Skins ***PLAYERS BEWARE*** SPOILERS lurk in the depths below. We strongly recommend playing this FM first so you don't spoil the fun for yourself!

How do I get out of the area with the and I can't find any other way deeper into the city

I'm now considering the .xcf files as being in effect the source texture for the game fonts, at least those that have been bitmap edited in GIMP. So that's an argument for putting them in the TDM assets repo. But, in any event, they do need to be backed up somewhere official.

This topic is going in different directions and it is difficult to tell if we all are in the same page. Facts: Stgatilov wants to change (improve, I guess) something and while implementing the change he realizes he will break some mission in the process. Mappers have been including (now obsolete) core files in their missions and the developer wants to know why these files were included in the first place, as in: the purpose. Changes in two mission are unavoidable, unless the authors go back and revisit the entire logic of their missions. Changes in eight missions are avoidable, in the sense that missions remain essentially the same with or without these changes. Regardless, if the improvements are to be implemented ten missions need to be reviewed and updated. Now my opinion: Considering how the topic is going the next time Stgatilov wants to improve something similar he might think it twice (we all lose because of ten missions). If these same improvements were to be implemented in the future chances are not ten but fifteen missions would have to be reviewed and updated which begs the question, does the inclusion of core files in missions put the present and future development of some areas at risk? No, as long as things remain under control: preserve what must be preserved, encourage and support innovations, identify and address trends. This requires an effort by all parties involved.

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.

@HMartI am not sure that is correct - you can even see in your screenshot that the green or "y" areas of the normal map are not shadowed correctly in game relative your point light. They are in shadow where they should be lit and the appear illuminated from the bottom when the light source is above. Here is another example: OpenGL: DirectX: Notice in DX how light source hits the tops of the tiles and shadows the bottom - where as this is inverted in openGL which does not look physically correct to me given the light position. It is very confusing given the legacy of the game being OpenGL, but I have learned from (painful) experience that directx formatted normals are what look physically correct in the game, at least in my opinion.

i want to try darkradiant on linux. Not sure how heavy the software is. i don't want to abuse this poor thing Now i am in the process of researching new SSD replacement & GaN charger. i have found a primer on magnetic spinning disk & the underlying technology of solid state drive but i still found it hard to grok the magic behind this technologies cylinder, head and track number.. That's the last thing I heard when I was messing around with the solaris installer

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.

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

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... edit: Incorrect info so ignore it any mod is free to delete this if he/she wants.

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.

Could be something funky going on with our implicit RGTC compression. We use a Microsoft BC format for pre-compressed normals but our on-the-fly encoder is supposed to use standard OpenGL tangent space normals. I wonder if the work to fix BC loading had some unintended effect on uncompressed loading? Maybe @orbweaver can be convinced to take a 2nd look?

This is the continuation of my first post above. Weeks ago i got a string of bad days. My main PC(elitedesk 800 g3) suffered a SSD failure and i noticed my thinkpad charger have an exposed wire. So i decided to dust off my old lenovo ideapad(ideacrap) yesterday. The spec is i3 6th generation, 4 gigs of RAM, 2.5" 500GB spinning drive and it's equipped with Intel HD & Nvidia GT 920MX. It runs Ubuntu mate 20.04 with Nvidia proprietary driver version 470 installed on it. I tried running TDM 2.12 on it and i got a somewhat 'playable' framerate at 25-33 FPS. I could hear this poor thing groaning when running TDM. It got hot quickly around 25-30 minutes into game.

"Undead hogwarts" is a fantastic description lol. As for your question, that door is purely decorative, it was meant to represent the front entrance. You cant actually traverse it. Sorry for the confusion

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

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?

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

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.

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