Search the Community

Yeah, that is a true aspect. Which is why I think there could be one of two approaches if this happened: Either make breakable lights a new entity for some lamps that want to feature them, so just as you have "atdm_lamp_1" and "atdm_lamp_1_unlit" you'd have an "atdm_lamp_1_breakable"... or if we implemented it for all lamps retroactively, it should come at the cost of AI becoming suspicious whenever they see a broken lamp just like when they notice a rope arrow, in which case the player choosing to go down this route comes at the cost of attracting attention and possibly ruining their stealth score.

I couldn't help thinking of another realism related suggestion, don't know if it was discussed before but it seemed like an interesting idea. If this were to be changed on existing lights by default, it would have minor gameplay implications, but the sort that make missions easier in a fair way. So... electric lights: Like the real ones of the era, they're implied to use incandescent light bulbs... the kind that in reality will explore and shatter upon the smallest impact, and which like real lamps are encased in glass or paper. In any realistic scenario, shooting a broadhead arrow at a lamp or even throwing a rock at it would cause it to go through the glass and break the light bulb inside. Is it wrong to imagine TDM emulating this behavior as a gameplay mechanic? Just as you can shoot water arrows at flame based lights to put them out, you'd shoot broadhead arrows at electric lights to disable them... you must however hit the glass precisely, there's no room for error and it must be a perfect shot. As a way to compensate for the benefit, AI can treat this as suspicious and become alert if seeing or hearing a lamp break, or finding a broken lamp at any time if that's deemed to provide better balance. A technical look at implementing this: Just as broadhead arrows can go and stick through small soft objects such as books, they should do the same if you hit the glass material on a lamp, while of course still bouncing off if you hit metal: Lamp glass would need a special material flag that sends a signal to the entity upon collisions but allows arrows to go through, unlike glass in other parts of the world which is meant to act as solid and changing that everywhere would break a lot of things. When pierced by an arrow, the lamp should immediately turn itself off while playing a broken glass sound and spawning a few glass particles. The glass material should be hidden if the model is a transparent surface, or replaced with a broken glass texture in case the glass is painted on a lamp model without an interior... obviously this would be done by defining a broken skin for the entity to switch to. This does imply a few complexities which should be manageable: Existing lamps supporting this behavior will need new skins and in a few cases new textures, the def must include a new skin variable similar to the lit / unlit skins in this case a broken skin. Any electric light may be connected to a light switch, we don't want toggling the switch to bring the light bulb back to life... as such a flag to permanently disable triggering the light from that point on would be required. For special purposes such as scripted events to reset the world, we should allow an event to unbreak lamps, setting their state back to being lit / unlit while re-enabling trigger toggling. What do you think about this idea and who else wants it? Would it be worth the trouble to try and implement? If so should it only be done for new lights or as a separate entity definition of existing ones, or would the change be welcome retroactively for existing missions without players and FM authors alike feeling it makes them too easy?

Oh my gosh, thank you for this! After reading what you just said, I realized I've in fact noticed the same thing in another program, but assumed it must be something completely unrelated: I've been working on creasing a CPU based voxel raytracing engine in Python, for which I settled with using PyGame. When the time came to implement first person camera control using the mouse, I noticed it did not work initially... however if I told my code to hide the mouse pointer first, locking it in the center of the window started working. It must be the same thing here in some form, Wayland likely has some very particular expectation on how the mouse pointer must be set in order to be locked. In fact just a few days ago, I tried a virtual worlds software called Vircadia / Overte again to see how it's been progressing. I activated mouse look mode and guess what happened: The exact same behavior of the view spinning endlessly as the cursor drifts away from the center due to lack of locking. So it's clearly happening to many things and not just GTK / WxWidgets related... but no all of them, most games (including TDM itself) work perfectly fine and mouse control never breaks. I'll try your solution later and mention the results, likely tomorrow as it's late now and I need to head off. If it works that would be incredible! At least as a workaround, we could simply not hide the cursor on Wayland, which will look ugly but at least allow using DR without needing hacks until they can solve whatever is happening on their end. Also Plasma 6 was just released, my distribution (Manjaro) will likely be getting it a couple of weeks or at most months from now. I'm curious how that will affect it: Hopefully it won't make the issue worse, but just in case I'd be happy to have a solution in Radiant before then.

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.

Another leak in Written in Stone near start (230 -1820 65): This case is more interesting because it is not just light leaking vs not leaking through a wall. Here we see view-dependent scissoring rectangle which limits the light effect. The light source is in the farthest area behind a wall (on the middle of the two far visportals). There is no way to cast a ray from the light source through visportals that would reach the viewer area: if you hit one of the far portals, then you surely don't hit the near portals. So the frontend decides that the light is not active in the viewer's area. Then the light scissor is bounding rectangle around all the visportals. Normally, the wall in between should occlude the light, but apparently it was set to noshadows. This wall seals the areas, so this is the same kind of bad input as usual. But the resulting behavior is indeed interesting. So I wonder how should we fix it @Amadeus @Dragofer

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

Hi, I've tried to install the latest version of TDM four times now (no previous installation), each time I get the same error: ERROR: Unexpected CURL error 56 on URL The urls seem to change (examples are http://darkmod.taaki.za.net/release/zipsync/release/release200/tdm_textures_metal01.pk4, /tdm_models02.pk4, /tdm_textures_carpet01.pk4) but the installation always fails around 20% of the way through. Am I doing something wrong? I tried the default mirror and the German mirror (also version 211 just in case). I'm using Windows 10 (64 bit) and don't seem to be having any internet issues that would cause the error. Any help would be appreciated!

There is nothing to upload anywhere unless the ask is to create an AutoHotKey executable in which case false positives would easily become my new nightmare. Thanks but I'll pass! This one truly is a proof of concept. I have been using this hack (with its shortcomings) since @Obsttorte and I first worked on it and I am convinced this could become a great project for an eager developer. Controlling the speed with the mouse-wheel not only feels natural but it would free us from the 3-speed limit and make some keys obsolete. An all-around improvement for those that may (optionally) use it.

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

Nice - did you find a solution for how to avoid it clipping into walls or other solid objects when coming too close? Off the top of my head there was also a need to handle its behaviour in case the player gets submerged, and various other ToDo's.

I think this will always be a divide. Engine coders will want a universal behavior that acts the same way across all missions. So if we want to offer the additional benefits of Shadow Maps, we will need to break lots of missions and then work to fix them. Mappers will probably want material or entity flags that force these behaviors so that they can force usage where they prefer. I think defaulting to consistent with Stencil rules is a good idea. Maybe this is a good case for using mission.cfg and have it force the cvars to enable the features?

In that case I could indeed use a pk4 with the name Unofficial_Patch. If the last one wins this or Wesp5 should be good :)! P.S.: I have released a new update where all loose files are in tdmup.pk4 now. Also I included nbohr1more's new torches...

Yes. It's a case by case exercise. We have the tools and we have the knowledge. We just need the will to do it. A pk4 is just a zip with a pk4 extension. If you pack the Unofficial Patch (except the "fms" folder) players can easily install it and remove it. Give it a try, pack it and give it a name, in example: z_unofficial_patch_wesp5.pk4 Test it.

My impression was that the unofficial patch has become a large collection of various tweaks and features by various authors, or at least that's what it was being marketed as. Making it modular has significant advantages for those who might want certain parts, rather than the exact same combination as the one you endorsed. It also makes your patch collection more futureproof in case you add stuff that not everyone wants to have. In any case, it's advisable to at least adapt the file structure to the new addon conventions so that players are able to install other addons alongside yours.

For easier inspection of various culling algorithms, I created a new debug cvar. It fixes the camera position that renderer frontend uses for culling, but allows player to fly around and see the same objects from different view point. Don't expect perfectly valid/sane picture, but I think it reliably shows which objects are sent to OpenGL for rendering. Here is the demonstration (bottom-left is clipped away in this video, but I hope it is clear anyway): It will be available in the next dev build. Maybe someone will find it useful for analyzing overdraw? P.S. Aside from that, "r_showtris 2" + "r_useScissor 0" should be useful for overdraw analysis too. It is questionable though whether you should disable r_useScissor in this case...

TDM Modpack v4.0 This new version of the Modpack is intended to be a long-term release. The Modpack is mature and stable enough to stay for some time how it is today, right where I want it to be: the foundation on which you build your favorite set of Mods for The Dark Mod. Good care was put to make sure the mods included in the Modpack stay true to TDM and neither the missions nor the gameplay are altered in any relevant way. Yes, we have more tools and skills at our disposal but it is up to you, the player, to make use of them or not. Play The Dark Mod your way. Compatible with 2.12 ONLY If you have previous versions of the Modpack I suggest you start fresh: disable and delete old mods. Use the mods included in version 4.0 from now on. TDM 2.12 introduces a great new feature and we can now have different mods from different sources running in parallel. Thanks @MirceaKitsune for pushing! Thanks @Dragofer for opening this door! What's more for 2.12 internal resources for mods have doubled and we can now load more mods than ever before and we are grateful for this! Thank you, @stgatilov! What's new in version 4.0? Starting with this release I am getting rid of the individual versioning and all mods are now at the same version (4.0 in this case). "TDM Modpack" is now the name of the project and the previous main "pack" has been split into two standalone mods: "Core Essentials" and the "Skill Upgrade". (The Skills are further split into their own packages and if you don't want a particular skill just look for the relevant pk4 and remove it). SHOULDERING BOOST - Decommissioned In TDM 2.12 we can now mantle while carrying bodies and the "Shouldering Boost" mod is no longer relevant and it has been decommissioned. In this new release of TDM we can also mantle while carrying objects therefore double thanks to @Daft Mugi for these quality of life improvements. Truly appreciated, thanks! SIMPLE SUBTITLES - New! Work on the subtitles is in progress and for the next version of TDM it is expected that players will be able to customize how subs are displayed on screen but until then, this new standalone mod offers an alternative for players looking for a rather simplistic presentation. Enable "Simple Subtitles", go to the audio settings and set the scope you prefer: Story [default]: Story only On: Story and general speech (Give it a try!) Off: Disable subtitles You can find more details of the mod in the opening post or in the readme included in the download. We must thank @Geep, @datiswous and @stgatilov (among other contributors) for the good work on the subtitles so far! Well done, guys! SMART OBJECTS - Present and Future Sometimes it is difficult to tell if an object is being held or not and the "Smart Objects" mod (now part of "Core Essentials") gets a little update and whenever you manipulate an object three dots [...] are displayed on screen: These three dots are a placeholder for real names, something I plan on addressing as a separate mod in the coming weeks... Here is the relevant topic: Nameless objects... a missed opportunity Stay tuned. INVENTORY MENU - Reworked The TDM user interface suffers from gigantism in some areas and the inventory menu has been re-worked and it is now delivered in a more compact format: The menu is 15% smaller and while the text has the same size as before item names are sometimes cut and I added a tip at the bottom to make sure the full name is always available. The updated menu is part of the "Core Essentials" mod. MINOR TWEAKS In each release of the Modpack I always tweak something and in for 4.0 I changed many things internally. You shouldn't notice any of the changes but it is worth giving the improved Whistle Skill a try... Here is the full changelog: • v4.0 New release - Major reorganization and global revision: Compatible with TDM 2.12. - All mods now share the same version (4.0 in this case). - Previous "Modpack" split into "Core Essentials" and the "Skill Upgrade". - Skill mods presented in their own, standalone pk4. - CORE ESSENTIALS: New, re-worked inventory menu. - CORE ESSENTIALS: New high mantle sound for our protagonist. - CORE ESSENTIALS - LOOT ANIMATIONS: Added scroll animation for paintings. - CORE ESSENTIALS - SMART OBJECTS: Display onscreen a subtle signal (...) when holding an item. - CORE ESSENTIALS - SHOULDERING BOOST: Mod decommissioned (alternative included in TDM 2.12) - SKILL UPGRADE - MANIPULATION: Improved script, smaller footprint. - SKILL UPGRADE - DISTRACTION: New approach (again). - HUNTER BOW: Increased radius of gas arrow effect. - BASIC SUBTITLES: Initial release. That's pretty much it for now. Thanks site admins, developers, mappers, modders and members of the community but more importantly, thank you taffer, for playing and supporting The Dark Mod. The download can be found in the opening post. Cheers!

Welcome to the forums Ansome! And congrats on making it to beta phase!

What???? You're on Windows 7, from 2009, with updates that ended 4 years ago. Windows 10 Pro key is like 20$. Why do you feel it's fair to expect Microsoft to continue to support an OS that's 4 versions out of date? I really don't like defending M$, but in this case, this is a little much. I hope your Linux experiences are better than mine were, as even on bog standard hardware it was nothing but crash city and bugs on 3 different distros.

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

I fixed another case of clipping into the ceiling during a mantle that starts in the standing position and ends in the crouching position (a.k.a forced-crouch mantle). The fix is included in beta212-07. The fix changed a lot of code, so please let us know if you find any issues.

It seems the unsnapped vertices were a bit of a red herring. The cause was simpler: the textures just don't align. When copying a shader from a receding/slanting surface to another one, the texture is tilted/rotated (like the side of an inclined wall made of bricks: it will "point" downwards) and this, I assume, happens to the patch too. If you "unrotate" it so the side of the bricks stays parallel to the ground, there's a seam as the textures are misaligned. It became obvious when using a tiling surface. I have managed to align the slanted surfaces at eye level, but the farther up or down you go, and the more sides you add to the object, the more misaligned they get. With a flat texture like plaster and some trimming, it could be hidden quite well I think. In case this is useful to someone, or for any future noob, here are a few pictures:

in case you wonder my beard was white when i hit 25 only started getting some grey streaks in my hair in the last two years hehe. and for those younger here enjoy your youth while you have it at around 40 the problems start (just look at those receeding hairlines atrocious!!!), well if the hair was my only problem i could live with it hehe i also got gall stones kidney stones and a nasty fall which broke my back in two places at around that time. So enjoy it while you can or stay away from ladders

I've been meaning to suggest this for months, but the previous improvements have already made Layers so nice to work with that I just got lazy about this. But there's a few things I think could still be improved. And personally, I would prioritize the first one below, if I had to pick one. I haven't been following DR's development, so I don't know if any of this is already done and ready for the next release. But in case it's not, here goes. 1- it would be nice to be able to right-click a layer in the Layers panel, and have all the options to add to layer and move to layer and remove from layer, right there. This would make it much easier and quicker to manage layers. And, I personally keep adding prefixes to layer names, so that they're sorted in the list below, so I can find them easier, because the list gets big and confusing. This improvement would remove the need to do that. It would even remove the need for using this list, I think. 2- It would also be nice to add a new layer directly as child of another layer, just by right-clicking the intended parent layer. Currently, you have to click the New button at the bottom, and then manually drag the layer to its intended parent. Or when clicking New, the new layer could be created as child of the selected one. 3- I've suggested this one before, but I don't know if it's doable or not. It's harder to explain and I think the benefits aren't very obvious. It would be nice to override the visibility of objects that are contained in multiple layers, by toggling one of those layers on/off. So the layer you toggle, overrides their visibility. So regardless of whether its objects are visible or not, hiding this layer, would hide all of its objects, and vice versa. This can be useful when you have certain objects in their respective layers, but then you'd like to have also have a way to toggle all of them on/off at a single click. And with this improvement you could add them to a separate layer, and then just use that layer to override their visibility whenever you needed. For example, to get the ceilings of a whole bunch of rooms out of the way all at once, so you could have a clear view of the rooms while you put in furniture or path nodes or something. Currently, objects are always visible if any of the layers that contain them is visible, so this kind of thing can't be done. (And to be honest, because of that, currently it seems to me that there's no point having objects in multiple layers.) This is also useful for grouping things for easy group-selections. Arguably, you can also use selection sets for that, but the way you create and delete them makes them more suitable for quick and dirty one-time grouping, rather than something a little more indefinite. The two approaches have different levels of control, which makes them appropriate for different use cases.

I think I found another case of bug 6480 and post in Talbot 2: Return to the City. 274.26 -1039.08 184.71 -15.8 24.9 0.0

It's hard. I see what you are thinking about is a "bullet point" pattern, with or without a bullet point character. For that case, I suppose what we are trying to detect is: - the line starts with the bullet point pattern - a "J" character (say) with a shortened spacing, is somewhere in the line. - the line itself in the xd file is long enough to force a word wrap (let's just think about a single wrapping here) - the author assumed a particular word wrap point, and put in extra spaces in mid-line, immediately at the wrap point, so as to indent the latter part of the line, aligning with the indent of the first part. - the shortened-spacing J screws up the resulting alignment. Probably would need a script/program to winnow this down... ideally, that algorithm could also restrict attention to just Stone font. I'm OK with putting such an effort off for now, maybe revisiting it for 2.13.