Search the Community

My issue with the Gold filter in HR is that overpowers all colors making the game monochromatic. These artistic liberties work on short games but in long games once the novelty wears down it could make the game feel monotone. Something similar happens in Thief 4. The art director made the textures almost colorless to add a bleak and sad effect to the game, cool but overtime the player might feel the game is dull and boring. Colors not only give look but also feel. Bur regardless. Here's my attempt to Replicate the Gold Filter in Deus Ex Art Director's Cut OFF ON The Directors Cut has this Pinkish Copper Tone: ON

The Blender export scripts have been updated to work with the new Blender 4.1 series. In this Blender version, they removed "Autosmooth" altogether, along with the corresponding parts of the Python API. This meant that the "Use Autosmooth settings" option had to be removed from the LWO exporter, where it was previously the default setting. The new default is "Full", which smooths the whole mesh, giving similar behaviour to ASE models, although "None" is still an option if you want a completely unsmoothed mesh.

I tried the German translations for fm The Thiefs Den. Doesn't work. When I include the russion translation pack from Darkfate, the original German translations work as well. The translation package from Darkfate adds a lot more files, including the xd and map files.

The translation pack has the german string in the base pack rather than in the fm subfolder. I will fix it in the mission database. Edit: Fixed in the mission db Edit 2: Nope. Not exactly fixed. It seems that lang files in the mission string folder need to be "complete" because they fully override the core strings. If I am correct, this was broken in 2.11 when we permitted in-file overrides of core files in missions. Edit 3: Still broken in 2.10, rolling back to 2.07 Edit 4: Still broken in 2.07. Something has gotta be wrong with the translation specific to this mission. Edit 5: The core mission XD files don't use the strings so nothing happens if the lang files are in the strings/fm subfolder. Probably means that the translation packs "never worked" for many missions unless impacted players sought out special editions of the missions on Tels' server. What a mess. Fuzzy recollection time: I think Tels was trying to push the team to mass convert all missions to move XD data into strings/fm/english.lang but nobody wanted to broach it and even mission authors weren't happy about this way of handling things. If the translation pack takes precedence, the best way forward is to include the converted XD file into it. Testing... Edit 6: Couldn't get the XD update to work, so I decided to checkout Darkfate's version. It works flawlessly. I copied their pack into the standard translation pack and the added string files for the other languages worked as well. Darkfate's packs include map files so I'll need to study whether we can avoid that. Otherwise we are basically doubling our mission db or "damaging" our hosted versions to make them translatable. Since this mission is so small and probably will never be edited again we can probably use darkfate's version as-is.

Oops, sorry, I forgot about those. I'll work on that soon.

I was wondering when you plan to include these subtitles + the ones I made for The Heart of Saint Mattis . It didn't work out that way, but still impressive. 5 missions in 6 years.

That is one reason. That is 2 more reasons. You'd like a script that, if you had to run it again, would "do the right thing". Unfortunately, that right thing is very hard to program, and needs IMHO to be both bidirectional and with a better method of string version control, to support both the FM author's updates and potentially multiple translators. Yes, another reason. Currently, it is my understanding that updating an FM (from the non-converted copy) and running the conversion script again causes mis-alignment of newly-generated #str values and previous .lang #str values. Another important cause of "nobody is making these language packs" is that Dark Radiant at best tolerates converted FMs. It offers no special translation support, as expressed in this code comment: "...we don't have any support for parsing the mod-specific translation data...." [from DR's DifficultySettingsManager.cpp]. That's where we are now. So officially give up on FM Western translations? Or improve the #str system to make it work for everyone? Or invent a new system? A new system. What would that look like to the FM author? To a non-author translator

I wanted to internationalise The Hare in the Snare before I released it but I couldn't get the scripts to work and had some other questions as well. I posted about it Newbie Dark Radiant Questions and nobody replied, so I gave up. It being my first FM I didn't feel confident digging into it and just wanted to release the FM. I just got the impression that it wasn't a big deal and nobody cared about it. From memory, the script worked once but I needed to re-run it and just couldn't get it to work. It's also Perl which nobody really uses anymore. I think I recommended to a 'I want to help' person to convert it to Python, but that didn't go anywhere. I don't think you need the script though if you internationalise from the very beginning (i.e. create your own dictionaries). At the end of the day it's extra work for the mapper and if it adds too much overhead (i.e. is broken or is a PITA) then nobody is going to use it. https://wiki.thedarkmod.com/index.php?title=Internationalization

Interesting idea. Not sure about my upcoming time availability to help. A couple of concerns here - - I assume the popup words uses the "Informative Texts" slot, e.g., where you might see "Acquired 80 in Jewels", so it likely wouldn't interfere with that or with already-higher subtitles. - There are indications that #str is becoming unviable in FMs; see my just-posted: https://forums.thedarkmod.com/index.php?/topic/22434-western-language-support-in-2024/

In considering my possible upcoming TDM projects, such as upgrading some fonts to Latin-1 or "TDM Latin", I reviewed the current status of support for European Latin-based languages. Basically, for FMs, the translation system has fallen into disrepair and disuse (or perhaps kicked into the grave). Neither "converted" (i.e., #str using) FMs nor Language Packs are now being maintained and distributed by thedarkmod.com. As to other sites, for Cyrillic/Russian, DarkFate provides such resources. Are there any such sites in native Western European tongues, say, German, French, Italian, that likewise offer translated TDM FMs? So, turning back to thedarkmod.com, questions - - is Western Language support (outside the main menu system) officially dead? - if so, maybe it's time to stop pretending otherwise. - if not, should the converted #str system be revived, with better infrastructure? - or an alternative translation system be devised... if so, what? I'm just trying to identify work worth doing. (I started to draft a doc with a litany of problems with Western language support, and possible sub-projects to address them, but TL;DR. And really, not pertinent if support is considered dropped.) Thanks for your thoughts.

Nameless Objects Mod v1.0 Description: this mod adds names to almost all core objects players can grab and hold in their hands. ------------------------------------------------------------------- How to use: As of this moment the Mod only works if you have "Core Essentials", which is included in TDM Modpack v4.0. Make sure to have "Core Essentials" and then download the *.pk4 attached to this post and place it in your TDM folder. I try my best to provide stuff people can experience first hand to form an opinion. I suggest you try "Business as Usual" by Bikerdude since this mission includes quite a few items you can grab right at the beginning. ------------------------------------------------------------------- Technical: The mod consists in a couple of def files and a script. I had to include two defs because otherwise there can be issues related with inheritance. The script does most of the work and it will run in the background as soon as a mission starts. The script runs once but it takes its time (10 to 30 seconds) not to hinder performance. All this is transparent to you. ------------------------------------------------------------------ Future: I wouldn't like this to remain as a mod and I volunteer to add names to all core defs for 2.13. I would, of course, use the translation system so that names can be translated in the future to languages other than English. I can name all core defs in a couple of rainy mornings but the Development Team must guarantee this work won't go to waste. The idea is that we name all core objects today and we let it stay: nothing changes in the source code and nothing gets displayed on screen. We get stuff done in the background and someday perhaps, all or part of it sees the light in some form. ------------------------------------------------------------------ There are quite a few things that must be discussed and agreed before we get started but the first step is: yes or no. People that might be interested in supporting and helping with this initiative: @datiswous, @Geep. Cheers! z_nameless_objects_mod_v1.0.pk4

Thanks for your hard work and dedication whenever it gets completed.

In post https://forums.thedarkmod.com/index.php?/profile/254-orbweaver/&status=3994&type=status @nbohr1more found out what the Fixup Map functionality is for. But what does it actually do? Does it search for def references (to core?) that don't excist anymore and then link them to defs with the same name elswhere? Also I would recommend to change the name into something better understood what it is for. Fixup map could mean anything. And it should be documented in the wiki.

Good work. I would use it myself because eventhough I'm not stressed for keys it makes the controls easier if it's nice and close like the delete button to my arrow keys.

This was... great. I loved it. Tight, rich and well presented. Great voice work, great intro... But someone pooped out a ring, again. XD

Taffers, Time ago @Obsttorte and I worked on an AutoHotKey script that allows to control the player speed with the mouse wheel. In a further attempt to reduce the amount of critical keys this game demands I also created back then a script that allows the Left Alt Key to act as a lean modifier: Left Alt + W = Lean forward Left Alt + A = Lean left Left Alt + D = Lean right I never got around publishing the script because it isn't as good as it needs to be but I think we can debate regardless whether such a Lean Modifier Key would be welcomed in the core game or not. The most interesting aspect in my opinion is that we can claim back important keys such as Q and E and use them for other purposes. ---------------------------------------------------------------------- Here below is the script in case anyone wants to give it a try (you must be familiar with AutoHotKey). The required key bindings for the script to work are: Move forward [W], Strafe Left [A], Strafe Right [D] Lean Forward [Numpad8], Lean Left [Numpad4], Lean Right [Numpad6] You can of course change the script to your liking.... #IfWinActive ahk_exe TheDarkModx64.exe ; run only when TDM is in focus <!w:: while (GetKeyState("LAlt", "P") && GetKeyState("w", "P")) { Send {Blind}{Numpad8 down} } Send {Numpad8 up} return <!a:: while (GetKeyState("LAlt", "P") && GetKeyState("a", "P")) { Send {Blind}{Numpad4 down} } Send {Numpad4 up} return <!d:: while (GetKeyState("LAlt", "P") && GetKeyState("d", "P")) { Send {Blind}{Numpad6 down} } Send {Numpad6 up} return Cheers!

Does this work? https://www.pcgamingwiki.com/wiki/Thief#Disable_shroud_effect_.28black.2Fwhite_fog_at_screen_edges.29

Ok, but you could also load all maps in your campaign, but in a different order. Or you could make a copy of the map and change some things. So it doesn't have to be an entirally different mission (which indeed might be too much work). So for example the first mission has an objective to place the plans to build a bridge over the river in a specific place. Then the next mission has that bridge (map1), or does not have that bridge (map2). Mapper only has to make a copy of the map and remove the bridge (and maybe a small amount of other things). I just think that having only one specific order is pretty restrictive. But if it's a lot of work to implement it might not be worth it.

Are you going to build two separate missions knowing that player will only see one of them? I think this is "cool in theory", but in reality using such a feature requires tremendous amount of work from mapper, so nobody will use it.

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as: Font Files Font Metrics & DAT File Format Font Bitmaps in DDS Files ExportFontToDoom3 Q3Font Refont As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files: 1 Cyrillic version for TDM's russian map 3 variants for TDM's custom english/european char map. One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs. For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.

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.

God knows since when have I last registered or posted on a traditional internet forum, but had to do so to pay my respects for the developers and map makers of this game. I have no history of the original thief series, and had no expectations for the mod. This is the first FM I played. After running around in a bit of a haste, becoming increasingly desperate of the complexity of the map, I learned to enjoy the feeling of being lost, calmed down and started to pay attention to the surroundings and listening to the ambient sounds and music. It is a truly immersive experience. I do have to admit that I could not find the entrance to the mansion, and had to resolve to a walkthrough to figure out how to enter, and at the end of the day did not manage to finish the mission. This mod is a great achievement, thank you for all the work and passion you have put into it.

To the "Path Nodes" wiki article, I've added a few sentences about path_follow_actor. It mentions that it currently doesn't support the actor being the player, and has pointers to the new bug report and the workaround given in this thread. The entry for path_follow_actor in the Entity Database now reads "... actor (= other AI, not player)...

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.

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.