Search the Community

There are many uses of this texture, and all of them use this compression algorithm. Perhaps replace it with full black texture would be better, since it already works that way. I wonder why this texture was even created with (1, 1, 1)... //matt black - there are already blacks but cannot get _black nor bc_black to reference as diffusemap // NB: this texture still has default specular reflections. For complete black, use black_pure below textures/darkmod/sfx/black_matt { qer_editorimage textures/darkmod/sfx/black_matt_ed diffusemap textures/darkmod/sfx/black_matt } The original code comes from 2008. And there is also 4151, where black_pure and white_pure materials were added. I hope someone familiar with assets will help decide

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

Thanks. Those methods might not work well unfortunately: Using an objective is overkill as they're meant to be standard characters you dynamically drop to the map and should just work... triggering would have worked but apart from the AI being made to patrol, I don't think it's possible for a def to reference another def as a target since those need to be linked on the map and there's no name for the AI to refer to the attachment by for a trigger. What do attached lights that turn off when the wearer dies use? Actually I think the Automaton has that so I can probably look at its example for the lamp component. It probably wouldn't work for my rotator though, stopping rotation is different from turning off a light... unless the light is also targeted or uses the SR system so I can reach the "use" stimuli via spawnargs after all? Another option would be having my fan as a texture, it's thin enough anyway: I define a version of the material that rotates and one that doesn't then switch the skin. But then the question becomes how does the AI change the skin of an attached entity on death? And a flat surface is uglier anyway I want to be up to date with quality standards so I'll have to think about this.

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.

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.

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

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.

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.

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

Wasn't it also to do with map file size? if you use a single model and reference it 100 times it will be a smaller/simpler map file than if you duplicate a func_static 100 times. I least I think I read that somewhere...

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?

I am going to sort-of reveal that this is loosely like the nature of my upcoming mission. I noted it here when JackFarmer asked about things that are coming along in this post: https://forums.thedarkmod.com/index.php?/profile/37993-jackfarmer/&status=3943&type=status It too is a builder church. The player is requested by a hopefully famous character in another mission to handle some business that is affecting the congregation. I am looking to invoke some info and history laid down in other missions as a hook story.

I created the page: https://wiki.thedarkmod.com/index.php?title=Lightgem In the source I placed the following text: <!-- Page text made by forum user Fiver: https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/&do=findComment&comment=491145 --> Personally I think the page isn't really necessary because the info is already present under HUD.

No warnings during dmap re: the patch, how do I check if a patch has a "[0..1] non-overlapping texcoords"? Is it correct in interpreting that to mean the texture has been fit to the patch? If so then yes. This is the patch copied from DR if that helps: <?xml version="1.0" encoding="utf-8"?> <map version="1" format="portable"> <layers> <layer id="0" name="Default" parentId="-1" active="true" hidden="false"/> </layers> <selectionGroups> <selectionGroup id="415" name=""/> <selectionGroup id="416" name=""/> <selectionGroup id="417" name=""/> <selectionGroup id="418" name=""/> <selectionGroup id="420" name=""/> <selectionGroup id="421" name=""/> <selectionGroup id="423" name=""/> <selectionGroup id="424" name=""/> </selectionGroups> <selectionSets/> <properties> <property key="EditTimeInSeconds" value="20837"/> <property key="LastCameraAngle" value="69 332.186 0"/> <property key="LastCameraPosition" value="20.0088 1653.64 531.677"/> <property key="LastShaderClipboardMaterial" value="textures/darkmod/nature/snow/snow_rough01"/> </properties> <entity number="0"> <primitives> <patch number="0" width="3" height="3" fixedSubdivisions="false"> <material name="textures/darkmod/weather/rain2_heavy2024mtr"/> <controlVertices> <controlVertex row="0" column="0" x="-448.000000" y="1712.000000" z="720.000000" u="0" v="0"/> <controlVertex row="1" column="0" x="-448.000000" y="1568.000000" z="720.000000" u="0" v="0.500000"/> <controlVertex row="2" column="0" x="-448.000000" y="1424.000000" z="720.000000" u="0" v="1.000000"/> <controlVertex row="0" column="1" x="-76.000000" y="1712.000000" z="720.000000" u="0.500000" v="0"/> <controlVertex row="1" column="1" x="-76.000000" y="1568.000000" z="720.000000" u="0.500000" v="0.500000"/> <controlVertex row="2" column="1" x="-76.000000" y="1424.000000" z="720.000000" u="0.500000" v="1.000000"/> <controlVertex row="0" column="2" x="296.000000" y="1712.000000" z="720.000000" u="1.000000" v="0"/> <controlVertex row="1" column="2" x="296.000000" y="1568.000000" z="720.000000" u="1.000000" v="0.500000"/> <controlVertex row="2" column="2" x="296.000000" y="1424.000000" z="720.000000" u="1.000000" v="1.000000"/> </controlVertices> <layers> <layer id="0"/> </layers> <selectionGroups/> <selectionSets/> </patch> </primitives> <keyValues> <keyValue key="classname" value="worldspawn"/> <keyValue key="difficulty0Name" value="easy"/> <keyValue key="difficulty1Name" value="medium"/> <keyValue key="difficulty2Name" value="hard"/> <keyValue key="shop_skip" value="1"/> </keyValues> <layers> <layer id="0"/> </layers> <selectionGroups/> <selectionSets/> </entity> </map>

Looking at the material file wiki page: Frob Highlight Stage isn't needed anymore since 2.11 right? I thought I understood that there might still be a reason to use it sometime. If not, I'll update that wiki page. Edit: The info is actually already there, but in a confusing way.

@Frost_SalamanderIt has been a good minute since i've played with particle collisions with rain, however I decided to revisit it after seeing your post and I can't seem to get it working. @stgatilov could you please confirm if this is the right flow as it doesn't seem to be working in my map: 1) Create a .prt file containing: particle rain2_heavy2024 { { count 100 material textures/particles/drop2 time 0.500 cycles 0.000 bunching 1.000 distribution rect 0.000 0.000 0.000 direction cone "0.000" orientation aimed 0.000 0.040 speed "1000.000" size "0.500" aspect "1.000" randomDistribution 0.000 fadeIn 0.200 fadeOut 0.000 color 0.040 0.040 0.040 1.000 fadeColor 0.000 0.000 0.000 1.000 offset 0.000 0.000 0.000 gravity 0.000 collisionStatic mapLayout texture 512 512 } } 2) Create a .mtr file containing: textures/darkmod/weather/rain2_heavy2024mtr { deform particle rain2_heavy2024 qer_editorimage textures/editor/rain nonsolid noshadows { //needed to emit particles blend filter map _white } } 3) Create the appropriate patch in game applying the above texture to it (with the texture fit to it and it facing down) 4) dmap missionname.map 5) runparticle missionname.map But ingame the rain just ignores the brushes and falls right through: Even using "particle_collision_static_blocker" "1" on this water entity, had no impact

https://www.waferworld.com/post/why-is-germanium-making-a-comeback-in-the-semiconductor-industry germanium was the material used in the first transistor but was harder to work with, so it got waylaid when silicon was discovered. it does have better charge carrying capabilities and is very stable, with the advanced fabrication technology today it made sense. since it also has 3 times the electron movement speed compared to silicon

aye lots of experiments going on atm, germanium is also making a comeback as a semiconductor material in cpu's mostly hybrid silicon/germanium though.