Search the Community

If you already know this ignore it but if you don't, then know that if's in materials stages turn on and off those stages, so you need to make sure you are setting parm11 to a valid value above zero in a script somewhere. But if removing those, didn't solved the problem, then the problem could be the vertex colors itself, are you sure the model has the correct vertex color info on it? Afaik the engine only supports grayscale vertex colors in the RGB format no alpha. Also instead of blend diffusemap keyword try the blend add (gl_src_one gl_dst_one) not sure if this matters but the basic example for vertex colors in this link uses it. I haven't used vertex blending for a very long time so all of this is rusty on my mind unfortunately. Also not sure what you mean with ""lawn_vertex_blend" is the vertex-blended DDS image file exported from Blender and is also referenced in the .ase file." but a material name like yours "textures/darkmod/map_specific/lawn_vertex_blend" shouldn't be a link to a real texture, in reality that is just a virtual path to a fake folder that DarkRadient uses to display in the media section of the editor. You can have a material with just a single word on its name and it will show in the media tab, just not inside a folder but in the global space. it is like this: virtual path/material name { material code } or material name { material code }

DarkRadiant 3.8.0 is ready for download. What's new: Feature: Support new frob-related material keywords Improvement: Mission selection list in Game setup is not alphabetically sorted Improvement: Better distinction between inherited and regular spawnargs Improvement: Silence sound shader button Improvement: Add Reload Definitions button to Model Chooser Fixed: Model Selector widgets are cut off and flicker constantly on Linux Fixed: DarkRadiant will not start without Dark Mod plugins Fixed: GenericEntityNode not calculating the direction correctly with "editor_rotatable" Fixed: RenderableArrow not drawing the tip correctly for arbitrary rotations Fixed: Light Inspector crashes on Linux Fixed: Models glitch out when filtering then showing them Fixed: Skin Editor: models not centered well in preview Fixed: "Copy Resource Path" includes top level folders Fixed: Skin Editor: internal test skins are shown if Material Editor was open previously Fixed: Changing Game/Project doesn't update loaded assets correctly Fixed: Model Chooser: initially hidden materials aren't revealed when enabling them Fixed: Choosing AI entity class 'atdm:townsfolk_commoner_update' causes crash Fixed: Sporadic assertion failure on shutdown due to LocalBitmapArtProvider destruction Fixed: Prefab Selector spams infinite error dialogs on Linux Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.8.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.

We didn't make the holidays (such a busy time of year) so here's a New Year's gift, an unusual little mission. Window of Opportunity Recover an item for a regretful trader out in a wilderness setting, and discover more! Available within the in-game mission downloader or: Download: http://www.thedarkmo...ndetails/?id=79 Alternative: https://drive.google...WTMzQXZtMVFBSG8 Some unorthodox gameplay on regular/ghost difficulties. (Arachnophobes might prefer short mode...) Please expect to need your lantern in regular and ghost modes! Short ("easy") mode is a smaller map, so if you are looking for areas others reference below, or 100% of the loot, you'll need to play on another mode. I wanted to create my first mission before I became influenced by too many others' ideas, and limited myself to what has been done before. As such, this mission is not set in a city/town, and has some features that are likely to be provocative. There's a section some really like, which others don't, either way I kept it short to not last too long. That being said, I hope you do find it fun! :-) Special thanks to those who provided valuable testing and feedback: Goldwell, Kyyrma, plotzzz, 161803398874989, PPoe & Bikerdude (who also contributed a sound). (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] If you are having trouble finding the main objective, here's what to pay attention to in the mission for hints: There is a spot it's possible to get stuck on the ground in the corner by the cliff/rockfall where there's a rope laying on the ground, please take care if you poke around there!

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

IIUC, fresnel uses view direction and surface normal vectors. This is a comparison between simple brush cube and one with chamfered edges on geometry, both using the same tiling material: Brush cube is on the right; in the background you see a cube with chamfered edges. There is a thin line on the bottom of the brush cube, because it matches the normalmap, the mortar part of the bricks. But as soon as I change texture coordinates of the brush: While the chamfered cube has enough geometry to work with fresnel shader, even if I change texture coordinates: So it seems to work as described, it needs either geometry normals or details faked on normalmap. I think fresnel in other pre-pbr engines, like UE3, works the same or similar way.

Hm, I am not sure I follow. Shouldn't the behaviour of the Rim shader be independet of actual geometric complexity and normal map based complexity? If the answer is yes, then brushes should also look fine because the applied material provides geometric complexity. Reshade is awesome. I use it all the time to improve the visuals of old classics. The Post-Lightmaps-Era games just look so much better with some SSAO...

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

@stgatilov Can answer this one. I think there's an argument for having this as a material effect to make assets stand out but I am not sure about "tying it to the ambient" light when we eventually plan to have those lights globally render proper fresnel at some point.

On a slightly related note, why ambientrimcolor material keyword was removed in 2.11? Notes show that it was "unused" – was it even advertised to mappers and content creators?

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

You are correct in that is a partially unfair example in that dishonored 1/2 use a lot of “modern” gui conventions like text elements, progress bars, etc for a lot of it’s interactions and telegraphs pretty clearly to the player what context sensitive action will result on frob. There is a delay on some interactions, including picking up bodies, but this is to prevent unintended inputs, not to enable something like multiple control layers. The primary function of using frob on the body is to “pick it up” ie shoulder it. No idea why this is material to an an argument that this should be the result of frobbing a body? No one is even suggesting removing this kind of manipulation from the game. The examples I can think of this kind of drag mechanic: the modern deus ex and hitman games, both of which are interactions exclusive to bodies and don’t feature shouldering as a mechanics at all, and the fine grain physics manipulation modes you see in Bethesda games starting with Oblivion, which requires long pressing the interact key on a physics object to allow you to move it around. Incorrect: TDM does not have the ability to move “anything” as physics object and all of those games have physics systems which include objects the player can move around. Also not material as to why a fine grain limb manipulation and dragging mode should be the primary function of the frob key. No one is advocating removing the feature from the game, and you can get the exact behavior you seem to want by disabling the hold commands in the main menu.

I suggest you use the term "I", to make clear that it is something YOU want, and that you speak for yourself. But, as wesp5 mentioned, I don't really know what this is about, at all. And, I'm also wondering about all the newly registered people lately, who just arrived at this forum, and already want to revolutionize this mod. This is a thing I noticed 2 or 3 years ago, and which hasn't been present in the 15 years I play this mod and frequent these forums now. Really seems like a common thing these days, to not knock on the door, but kick it in, and stomp right in.

Dear mappers, please be aware of this decorative light option introduced in upcoming 2.10 It aims to highlight the light volume and produces something like the existing fog particle with the intended effect of better speed and arguably better visuals It looks like this in game The test map we have been testing recently is courtesy of Bikerdude: download To enable this effect you will need to mark your light material with the volumetricLight keyword, like this lights/test_mansion01_window04_vol { description "volumetricLight for mansion01 window04" volumetricLight { map lights/mansion01_window04 colored zeroClamp } } Volumetric lights use projection and falloff textures to generate the volumetric effect. With shadow maps on, they also take shadows in the account. There's also an optional parameter after volumetricLight that toggles max speed vs decent look mode. Credits: @peter_spy for the original test map and direction @Bikerdude for great support during the reintroduction effort this year @stgatilov for taking the implementation on a completely different quality level @all for being cool and awesome

TDM has tons of textures from "free" texture resources that do not allow redistribution and cannot be incorporated into a commercial project. Someone would need to create a huge replacement pack of textures that do not break the look of existing missions and do not infringe on the copyrighted textures. Also, many artists who contributed to this project do not want 3rd party entities to use their work in commercial projects. They intended the models, textures, sounds, animations to be exclusively used for Darkmod content. You would either have to replace ALL assets or contact every contributor and ask them to re-license their assets. Many contributors are no longer active with the project and haven't visited the forums in years so it would be no easy feat. I cannot speak to Debian policy but I think that they treat installers that add non-free content the same as non-free content itself. One could argue that Steam is such an installer but I guess Debian would counter that there are a few fully Libre games on Steam. I think Debian, Ubuntu, or Linux Mint need to consider a repo that allows for games (etc) that include non-libre content but intentionally offer this content for free to the community with no stipulations other than "don't try to sell it as a product".

The gamepad implementation allows for a great degree of flexibility to personalize settings, aside from a few minor issues that I mentioned here: https://forums.thedarkmod.com/index.php?/topic/22337-gamepad-bindings/ I would say that playing TDM with a gamepad works very well, especially considering that it was implemented as experimental and hasn't been changed since then. If I could, I'd go back to 2021-you and congratulate you on buying that gamepad. I notice that your DarkmodPadbinds.cfg looks very different from mine...

It seems like more and more "thief" and "thief players" is becoming a short hand to dismiss community members earnest desire to improve the game - which happens to be a barely legally distinct "thief style" game which was made by thief fans for thief fans and is "designed to simulate the stealth gameplay of Thief". Who is the predominant player base of the game supposed to be beyond fans of the thief games? Is there some better avenue to find feedback for the game beyond this forum? FOSS and linux forums? I have seen maybe half a dozen posts from that segment. I am a thief fan, I play thief fms, my association with those games is what drives me to play and make things for this game. Are we supposed to pretend the original games are not a huge reason why most of us are here at all? TL;DR version:

Thanks! 1) Doing LONG_PRESS PAD_A (what I, for lack of knowledge, call "jump-mantle" or "_jumpmantle") differs from doing PRESS PAD_A ("_jump"). "_jumpmantle" differs from "_mantle", so they must be mapped to different button-calls. "_jumpmantle" differs from "_jump", so they must also be mapped to different button-calls. This appears to be the case, but it is not evident (or changeable) in DarkmodPadbinds.cfg. "_jumpmantle" seems to be hard coded to always connect to the same button as "_jump" but with a long press. It is as if bindPadButton PRESS PAD_A "_jump" is not actually just binding PRESS PAD_A to "_jump", but rather interpreted as "link PAD_A (regardless of button press time) to behave exactly like keyboard SPACE for short and long presses". I would have expected the default DarkmodPadbinds.cfg to explicitly read: bindPadButton PRESS PAD_A "_jump" bindPadButton LONG_PRESS PAD_A "_jumpmantle" bindPadButton PRESS PAD_B "_crouch" bindPadButton LONG_PRESS PAD_B "_mantle" ... but neither LONG_PRESS PAD_A or "_jumpmantle" is listed in the file. If there are actions "_jump" and "_mantle", I suppose there must also be an action "_jumpmantle" since it is possible for the player to do all those movements: * "_mantle" does the movements "crouch on the high surface, then stand up" * "_jumpmantle" idoes the movements "jump slightly forward, then land standing on the high surface" * "_jump" idoes the movements "jump up, then land exactly where you started" If the actions "_jump" and "_moveup" are not synonymous, then perhaps the action "_moveup" is what i call "_jumpmantle"? 2) Thanks for the link! It was useful in more than one way. I'll link to that page from https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings#Gamepad_Default_Bindings if I can get an account on the wiki, which proved more difficult than i thought (https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/). However, it does not answer my question how to find out the name ("<button>") used for a button on my gamepad. Basically, I would need to press the button on my gamepad and some program could tell me "That button is called 'PAD_A'". In my case, I have a gamepad "Logitech F310" (https://commons.wikimedia.org/wiki/File:Logitech_F310_Gamepad.jpg) which has a "Logitech button" (see image) that I want to use. I was hoping to find out the "button name" for that button and then edit DarkmodPadbinds.cfg to map it to a function. 3) ... but if that button has an "unusual name" that TDM does not recognize, then it may perhaps not work. E.g. if that button is called "PAD_LOGITECH" and TDM cannot recognize that name, then I cannot map anything to it via DarkmodPadbinds.cfg. Using QJoyPad I can map any keyboard key to it instead, as a workaround, but I cannot map MODIFIER to it (since MODIFIER cannot be set to a keyboard key). If current implementation is still called "experimental", then I must say it works very well; @cabalistic: kudos for that! I may not have continued playing TDM had it not worked with a gamepad.

It is possible that this is a setting that needs to be activated to work: https://mantisbt.org/forums/viewtopic.php?t=23221

I think we should deprecate parallel lights. The way they are implemented in Doom 3 only works intuitively if it is fully contained in a single visportal area, which is rarely the case. Otherwise, there are huge issue with area-portal graph and shadows. For something global like moonlight, the new parallelSky light should be used. If it is contains the whole level in its light volume, then the behavior should be well-defined as long as portalsky material is used to seal levels from the sky (not caulk or something similar). The light is supposed to come through the portalsky surfaces into all areas in this case. Are there any other usages of parallel lights?