Search the Community

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

This is what I personally know about it: No diffuse means "skip the diffuse path code for this light" essentially means don't add/mix this light color/texture color info unto the surface, only use it as a simple b&w light. No specular is essentially the same but for specular textures, it skips the specular component/code/calculation and makes the light less heavy by removing the specular effect. About performance impact, for today GPU's, I don't think is as important as it was in 2004, but still, I'm sure it does have a small impact on performance, for the better of course, specially if done for many lights, but will also make them way more unrealistic. Btw lights with both no diffuse and nospecular, were used for the "projected shadows" or lights used to project fake "shadows" unto surfaces, this was used in Doom 3 to simulate basic, shadow mapping, for rotating fans and grid materials that use alpha textures, all because stencil shadows ignore those. Now that TDM has real shadow mapping, IMO such lights are less necessary and I wouldn't recommend their use for such effect. Thou lights with no specular and no normal mapping, are still useful for some effects, like simulating casting colored light from painted glass, like something bellow, and they are faster then normal 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.

I don't know if it's mentioned anywhere else on the Wiki, but it's worth mentioning that the first global keywords are for sound: // Use on of the predefined surface types like: // none, metal, stone, flesh, glass, wood stone And this: //surftype15 //description "carpet This is a carpet texture." I think this is sound as well, but I also think 'description' does other stuff, for example for using with vine arrows: stone description "vine_friendly" If someone has a list (or link to code) where all this is defined for TDM so mappers are aware, that would be useful. I would also move the 'special keywords' section up so it's before the obsolete stuff - that old stuff needs to be relegated to the very bottom. I would also change the title of that section from 'No ambient and frob -stages needed' to something like 'Deprecated stages' and say it's just there for historical reference.

This can be removed as well, you don't need to specify texture map slots you don't use. In some cases you even shouldn't.

The problems with the lightening texture has vanished, moreover, the camera screens work now perfectly, I had here and there strange results (glass texture not showing up, lights do not show up) in 2.11 and the previous beta. Thank you @stgatilov

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>

@Geep Regarding 0.24 vs 0.25 font scale. I think there was purpose, though I can't say now which exactly. Maybe it was to ensure that all the text fits, maybe it was to make vertical padding symmetric. Anyway, why do you think 0.24 and 0.25 differ? I did not look in the code yet, but I think what engine does is 1) choose most suitable image, 2) render quad texture with it. Indeed, we can avoid some blurring if the pixel size of the quad exactly matches the image size. But I guess the engine counts font size in 640x480 virtual resolution. So even if the font size would be "12", it would later be stretched over whatever width you really have (if your aspect ratio is 16:9 then height would be stretched equally, but otherwise it would be stretched with different factor).

@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

In the first post of the other topic Geep proposed: Then Stgatilov's answer: But I think applying subtitles in different languages shouldn't be too hard I would think, but I don't know how the current translation system works. The engine should apply the correct subtitles based on the applied language setting, this doesn't need a whole new language system I think. Not sure who's going to write those subtitles though. I can only do Dutch and English and nobody needs Dutch I think. I suggest further discussion of this to take place in topic https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/

Yeah it would be cool to see some more detailed statistics and it’s a shame they aren’t really captured. Since we are talking about fan mission platforms, where players also make the content for the game, I feel like the best thing we’ve got is you can look at the number of content releases for the games. Keep in mind the graph counts campaigns as single missions - so for example NHAT and TBP both count as 1 mission. A good year for TDM has has approaching maybe 50% - mostly we’re 25-30%. https://www.ttlg.com/forums/showthread.php?t=152494 You could also look at the number of ratings thief missions get on https://www.thiefguild.com/ vs TDM ones, but that is pretty iffy in that you could chalk that up to more awareness of the site in the thief community than TDM Out of curiosity is there a reason a thief player can’t be a new player? I kind of think a player is a player and new players would be ones who are playing the dark mod who weren't? Is there disagreement the base of players most likely to pick up the game are fans of the thief games? They are certainly the most fruitful place to find feedback on the game beyond the sphere of this forum that I have seen. When we were trying to finish up SLL there was a lot of discussion on the forums about how long it had been since there was a release for the game. I am thankful that the stats show at least some stability over the years in terms of releases for TDM, but the trend for all of the games is decline. Not doing anything is a valid response if that’s what the devs want to do - it is not possible to provide evidence that any effort will slow that inertia. As a player and content maker I would just prefer trying to find feedback where it is offered from players who were willing to try the game but ultimately could not engage with it and see if there is anything that can be done within reason to ease them into the game. The game has a lot to offer imo. All those players are potential contributors - contributions in turn attract players - it’d be nice to see the cycle go on as long as it can.

Because that we would have to copy/paste all rain materials to introduce "deform particle" version. Note that we cannot delete "deform particle2" versions because they are already used, and they cannot be replaced that easily. Then we would have to copy everything again in order to add versions with collisions. But I'm sure mappers might want to create rain patches of different size, so we'll probably have to have versions with layout texture 1024 1024, layout texture 512 512, layout texture 256 256, etc. And then different mappers might have different feelings about the balance between quality and waiting time in case of layout linear, so we'll have many versions of snow too. All of this causes combinatorial explosion, and we'll get at least ten times more materials and particle decls than we have now, causing a lot of confusion. Perhaps combinatorial explosion can be avoided if these settings are specified in another file. I guess at that moment I was not brave enough to introduce a new type of decl files.

Particle collisions cannot be computed in realtime, particles are purely graphical effect which cannot interact with collisions. So the collisions have to be precomputed beforehand, just like dmap precomputes triangulations of brushes. Most of the nuances grow from here. It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings. Now that some people have some practice with this, should we change it? Most importantly, collisions are precomputed statically. If you move the emitter, the collision information becomes wrong. All objects which seem dynamic are automatically excluded from precomputation, so the particles will still go straight through all the guards and moveables. What do you mean by "default" behavior? Default behavior of what? particles? Like make all particle emitters stop on collisions automatically? What about cases when mapper wanted particles to pierce walls? What about moving particle emitters? The goal was to reduce amount of work actually. As soon as you are able to set one huge particle emitter over the whole map, I think you don't have to mess with it any more, just remember to execute runParticle occasionally when you want up-to-date collisions. Before that, mapper had to split the rain patch into many patches and manually tweak every patch so that it stops at proper height. As far as I understand, it was very time-consuming and painful. As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no? Yeah, this is a tough question. Texture layout: Only works properly if particle evolves exactly the same way if emitted from the same location. Interacts with texturing: requires you to set non-overlapping texcoords in 0..1 range on the emitting surface. The only option in TDM 2.08. Ok for straight-falling rain, but snow is out of question. Linear layout: Only works for a periodic system, i.e. the whole system exactly repeats itself after some time. Precomputation might take a lot of time, especially if you insist on a large period. [problem for maintainers like me] If particle code is changed in TDM engine, the collisions must be recomputed. Was added in TDM 2.09. Supports pretty much any kind of particles, although snow was the main goal.

I just recently became aware of this feature: https://wiki.thedarkmod.com/index.php?title=Particle_collisions_and_cutoff Unfortunately I completely missed it, as when I went to create weather effects in my FMs I just followed this (which doesn't mention it): https://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Page_3#Rain_and_Snow The point of this thread is to a) make people aware of it and b) gather feedback from any mappers that have used it so we can get some mapper-focused documentation in the Wiki. The page above is great for background information about how it works, but as a mapper I really just want to know: What are the limitations of this (i.e. when should it be used and when shouldn't it be used)? Why isn't it the default behaviour? Why all this work to get it into the map? What built-in support for it exists (particle definitions, materials, etc). Do I need to create all this stuff myself? Texture layout vs. Linear layout: what's the difference in the end, pros/cons, why would I use one over the other... Why does it need a separate command (runParticle)? Can this just not be bundled in with dmap? A clear, step-by-step instruction on how to implement it in a map from beginning to end using a simple use case. Tagging some users who have relevant experience with this: @stgatilov @Goldwell @Amadeus

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751 I suppose the main questions are: when should this spawnarg be used, if at all? why was it introduced in the first place? Can we get it documented properly on the Wiki so misuse isn't propagated? @stgatilov @Dragofer

I think there was a quirk in the engine that treated pure 0 black as an artist error so a small uplift was added to ensure proper light response. This was more critical when the ambient had a Fresnel component. The DXT1 encoding was to save on storage. I think that's a silly rationale since a pure single color texture could technically be represented by a single pixel. No pressing need to compress that or even a 32x32 texture but I suppose if someone is obsessed with saving texture storage they could choose png or a better dxt version. TLDR; Transparent \ Blend textures should be fine with 0,0,0 color and single color textures don't need aggressive compression. _black should be fine for all such materials.

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

This is caused by DXT1 compression of textures/darkmod/sfx/black_matt.tga. This image has constant color (1, 1, 1) everywhere, i.e. almost black. Previously, the image was compressed by OpenGL driver, so you could get different results depending on vendor. I got (0, 0, 0) everywhere, you probably got the same. But someone else on another vendor could get something else. Now, compression is done by our code, same for everyone. It compresses the color to (0, 1, 0). Obviously, this is a bit closer to (1, 1, 1) than (0, 0, 0) Notice that DXT1 uses 5 bits for red and blue but 6 bits for green. So while it is possible to represent 1/255 value for green, it is not possible to do the same for red and blue. However, this 1 tick adds a bit of green to the overly black picture, and then you apply huge gamma correction (basically take sqrt of all color components) and this green becomes noticeable. Some ways to fix the issue: Use _black texture. It is (0, 0, 0), and I am rather sure it will be compressed to (0, 0, 0) by all implementations. Modify textures/darkmod/sfx/black_matt to be full black (0, 0, 0). Add forceHighQuality to the stage which blends textures/darkmod/sfx/black_matt. Add DDS version of textures/darkmod/sfx/black_matt to core assets. Note that points 1, 2, 4 produce equivalent output, i.e. force texture to (0, 0, 0) color. Point 3 leaves the texture as (1, 1, 1), but there is no way to do this for all materials: the keyword has to be added to each material. Points 1 and 3 look bad because they fix the problem now, but don't stop the problem from happening again in the future.

Right, I forgot that's also a reason why TDM has every single texture from cgtextures listed in license.txt. But, according to current EULA, that might not be enough:

Sorry to resurrect an old thread, but what is the conclusion here? I'm particularly asking about textures.com, because in my latest FM (WIP) I've used tons of textures from there. When I first looked at it, I had concluded that it was OK to use them, but now I'm second guessing that because of this (also mentioned above): Please note that it is not allowed to release our images under Open Source licenses (even when the materials are modified). If you are working on an game that is released under an Open Source license, you need to release content that has been created using our materials under a closed source license. However, this here make me think it might be OK? From https://www.textures.com/support/faq-license#3d-model CAN I USE THE MATERIALS ON A 3D MODEL OR SCENE OR VIDEO GAME LEVEL WHICH I WILL OFFER OR SELL ON A DIGITAL MARKETPLACE? Regular textures may be bundled with 3D models, scenes or video game levels under the following conditions: you have customized the materials for the 3D model, scene or game level, all materials are actually used on the 3D model, in the scene or game level you are selling the model and materials in one package. In other words: do not use bundling as a loophole to sell a texture or material pack. Please add the following text in the documentation accompanying the model: "One or more textures bundled with this project have been created with images from Textures.com. These images may not be redistributed by default. Please visit www.textures.com for more information." IMPORTANT: the exception to this is any content in the Special Content categories: 3D Scans, 3D Scans Atlas, 3D Objects, 3D Foliage, Substance, PBR Materials, Decals, HDR Spheres, HDR Skies, Graphic Designs and 3D Ornaments. The materials in these categories may NOT be bundled with 3D models or scenes. This even applies when you modify the materials: modification does not mean you are allowed to bundle these types of materials. Again I'm specifically talking about using these are part of a fan mission, not the core game. To satisfy the conditions above, I will: customisation: all textures have been converted to different formats (.dds and .tga) or resized I won't include any textures in the .pk4 that aren't included in the mission the FM will be bundled into a single .pk4 package (and I'm obviously not selling it). I'm only using the 'regular textures', not PBR or 3D materials. I will include the text 'One ore more textures...' in the FM readme.

Looking at the code, the originals were "pm_mantle_pull 750" and "pm_mantle_pullFast 450". The new "pm_mantle_pull" value is "400". A "pm_mantle_pullFast" value of "450" would be slower than regular pull, not faster. With both being set to "400", they are at least similar. Other than that, it's subjective and the feedback from playtesters was positive. Also, referenced internally here: https://forums.thedarkmod.com/index.php?/topic/22256-movementcontrols-settings-in-main-menu/&do=findComment&comment=489158