Search the Community

I don't think there's a consensus, or a general opinion that there are "issues" with the existing weapons. It's rather that FM authors take the liberty to change things to what they think is better. Or different. Or whatever.

The training mission’s job is not cover the diversity of FMs across the entire platform. There are lots of stuff in volta universe missions which are not covered: explosive barrels, ammo crystals, loot you dislodge by shooting it with an arrow, completely different undead AI with a completely different damage model, etc Just like in northdale missions: neutral/hostile areas, in game shops, simplified lockpicks, etc Why would you need to be told any of this is happening by anything other than the game itself? That’s how games communicate: you play them.

Completely disagree it was a very good idea that unfortunately came too early with idSoftware RAGE 1 because hardware was still and is not truly ready for it. Megatexture is for textures, what UE5 nanite is for geometry, it permits huge amounts of texture data in a level and even totally unique textures per each surface, no repetition unlike older methods. MT isn't simple a giant texture slapped unto a level, it is a type of virtual texturing system, the MT is a huge "texture" but it's data, is not all drawn on a level at the same time, like a normal one is, it is broken into smaller squared peace's and those peace's into even smaller ones for LOD aka mipmapping, then those peace's are streamed in, in real time has the player moves around. Again IMO It is a very cool idea and if the hardware was fast enough, to stream it fast and it was possible to compress the MT data, to very small amounts and still keep good quality, it would be a fantastic system for very unique levels. Rage 1 world may look bad at close distance, but at medium to large distances imo it looks fantastic and totally unique.

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.

The Numbers don't lie. It has been 15 years since the release of TDM 1.0 in 2009. I think we should consider a contest to celebrate this. Further, the contest goal should be with the intention of motivating the completion of a campaign that can be deemed official. Here are some possible ways forward: Proposal 1: Middle mission(s) Authors are asked to create a mission that expands the story between "A New Job" and "Tears of St Lucia". This can involve escaping the heavily guarded city perimeter, stowing away on a ship or caravan, attempting to recruit a partner for St Lucia and failing, getting caught by Builders before arriving and having to escape their compound, getting lost in haunted woods on the way there, etc. Any interesting way that the connection between the two official missions can be expanded. Points are awarded for making explicit references to Corbin, St Lucia, and any story elements in the two official missions. If the resultant mission is of high enough quality, it can possibly be made into an official mission. If we get a number of excellent submissions and they do not cause logical inconsistencies, we might even be able to add two or more to the official list. Proposal 2: Intellectual Property distinct approximation of TDS missions Over the years, many have asked that we recreate Thief 1 \ 2 in this engine. Obviously we cannot do this due to copyright law but we could create similar missions and stories that approximate the Thief 1 or 2 designs. That said, I think that most of our audience has played these missions to death so it may be underwhelming to see them arrive in approximate form anyway. What might be better would be to develop a similar story to TDS and make missions that resemble what T1 \ T2 players were dreaming would arrive when TDS was announced and the first screen-shots were shown in gaming magazines. So take any TDS mission you like, examine the story arc and wildly re-interpret something similar but on a much grander scale. Since it's possible that two or more contestants will choose the same mission to re-interpret, we have a slot system were authors need to claim their preferred mission and if it is taken then they must select another one or lose some story points. The slots represent a sketch of what the mission author might try to do rather than a blueprint. If authors can come up with a mission that has almost no resemblance to any TDS mission but would make for a compelling story development in a similar story arc then that can be claimed as an alternative to a slot. Proposal 3: Same as proposal 2 but we stick with Thief 1 rather than TDS. Wildly re-interpret T1 based on what you may have dreamed of when reading the gaming magazines or playing the demo. Slots system to prevent duplicate submissions. Maybe with either proposals 3 and 4, we still require the use of Corbin as the protagonist and a connective enough story that they could also be adapted as middle missions for the official campaign if the team agrees on it. Proposal 4: Another "Connections" Contest. We just allow authors to connect any two missions with each other or expand the story of an existing series or single mission. So those are my thoughts. I'll leave it to players and mission authors to suggest other proposals and if we have some sort of consensus about the most popular proposals then we will make a poll. Realistically between now and October we may not be able to hold a contest with any strict guidelines ( and tricky issues with maintaining a distance to Thief IP ) so proposal 4 may still be the easiest option.

Why the sad face? Also, Kingsal would be better able to explain the changes, and he actually modified the script so that it is more TDM-friendly. This modified script is in Eye on the Prize and Moongate Ruckus

So this revised script is part of Kingsal's arrow mod, and the script tweaks a few values such as the ARROW_zoomdelay from "6" seconds to "3" and a few other things. I also thought this was the script that increases bow draw speed, but I guess that is done in the associated .def files instead. These tweaks were made so that gameplay would feel a bit more fluid when drawing and firing arrows.

The idea is that mapper can set spawnargs on map entity to override defaults from entityDef. If some entityDef is used only to dynamically spawn entity without any map entity, then it does not fit. I guess this is the case with arrow weapons, sadly. UPDATE: At some moment we discussed an option to specify "patches" to core entityDefs, but the idea never got far.

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

Could somebody update the article about the lightgem? 1. Add a sentence that a red frame around the lightgem indicates that it is at maximum intensity. (see https://bugs.thedarkmod.com/view.php?id=6525) 2. Remove the lingering quotation mark after "Stealth & Shadows".

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

Hello taffers, The campaign "Hidden Hands: Blood & Metal" consisting of five missions is now basically ready for beta testing (the briefing videos are missing and there are still some "real" speakers missing, at the moment there are tentative robot voices in these places, hope to replace them in the next two or three weeks). Unfortunately, the project has become somewhat more extensive than originally planned. It took me about two hours to test each mission. So you should allow at least12 hours for all five missions on the first run. Beta testing shall start at the beginning/middle of next week. The difficulty level is somewhere between "The Anomaly" and "The Lost Citadel". Some things are easier, others are not, but proper exploration and usage of the available resources/objects should always pave the way to success. Sign in here, if you are taff enough! Jack Testing thread:

@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.

Here's a link with the Engine, Game and Input file in case anyone would like to dig in but don't own or have the game installed. Either for Performance or Quality optimization: https://github.com/honzi/files/blob/master/Config/Thief/2014/ThiefEngine.ini

A visually breaking change is planned for 2.13 (6354). Environment mapping is used when material contains a stage like this: { blend add cubeMap env/gen3 texgen reflect } Historically, there are two separate shaders for this case: one if the material has bumpmapping, and one if it does not. Note that if the material has diffuse or specular stage, then bumpmap is added implicitly. The shader with bumpmap was apparently "tweaked" by someone in TDM and got several major differences: it has fresnel term output color is tonemapped to [0..1] range using X / (1 + X) the color multiplier is hardcoded to (0.4, 0.4, 0.4) I'd like to delete all of these differences and restore the same behavior as in non-bumpmapped case. It is also the same behavior which is used in both cases in Doom 3 BFG (and supposedly in Doom 3 too). Speaking of points 1 and 2, nobody will notice the difference except in rare corner cases. The point 3 however is serious. It is also the main reason behind the change. Right now nobody can tweak the intensity of environment mapping: if you try to set red/green/blue/rgb, these settings are simply ignored. Now the problem is that the intensity of most environment mapping materials will change. In core files I see text like this (stainglass_saint_01) : { blend add maskalpha cubeMap env/gen3 // tone down the reflection a bit //I see no evidence that these values do anything red Parm0 * 0.2 green Parm1 * 0.2 blue Parm2 * 0.2 texgen reflect } Since the default parameter was 0.4, after the change this material will get 2x less intensity. The situation is even worse if rgb multiplier is not specified, since then it will change from 0.4 to 1.0, i.e. envmapping will become 2.5 times brighter. I can probably collect the list of all materials using environment mapping, but I'm not sure I'll be able to check them all one by one. Perhaps I can delete existing rgb settings, blindly set "rgb 0.4" and hope for the best.

Plan B in case Joebarnin cannot get it right with immobilizations. By Any Other Name: attached to this post are the Bow/Arrow, Blackjack and Shortsword scripts updated to 2.12. I didn't take any liberties. Blame snatcher if something isn't right. @joebarnin, @stgatilov z_byanyothername_212_scripts.pk4

Found the White Flash Hex Value but not the one for the Shroud effect. I'm playing the Epic Version.

Venturing beyond the base game... A candle set consists of a candle holder and a candle attached to it. Core candle holders, candles and candle sets are properly named in v1.0 but mappers sometimes create their own candle sets and because of how these object are handled by the engine we end up with a "Candle holder" on screen. We can approach this puzzle in different ways but for the sake of simplicity in v1.1 everything is a "Candle", including single candle holders. Find v1.1 attached to this post. Remember you need the Core Essentials for the mod to work. z_nameless_objects_mod_v1.1.pk4

Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.

I override it so I can tweak the #define ARROW_ZOOMDELAY 3 //VOLTA MOD There's a whole bunch of reasons why I do this, one of which is because it makes shooting the bow easier for most players. I dont really want to get into a debate about if thats better or not but I would suggest you expose the variables in a way that authors can tweak them. I sent you a DM about this exact thing.

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.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

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!