Search the Community

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

The latest SVN (rev 10439 linux) has choppy (or reduced framerate) when the book angle changes while reading a book. Perhaps earlier dev releases as well, but I haven't used those. This is a bit hard to describe. Turning left and right normally seems fine. However, when turning left and right with the book on the screen, the book angle change is choppy. This can be tested with any book. The first book in the Training Mission works. This issue is more pronounced with a lower "com_maxFPS" value, such as 30, and it's less pronounced with a higher "com_maxFPS" value, such as 120. I originally noticed this issue with "com_maxFPS" set to 60. The 2.11 release does not have this problem. When the book angle changes, the view is very smooth. Even with "com_maxFPS" set to 30, the angle change is fairly smooth.

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

I just found this thread on ttlg listing Immersive Sims: https://www.ttlg.com/forums/showthread.php?t=151176

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

A@datiswous Ah yeah, well sorry, I was quiet busy and only visiting discord. First time here on the forums since months now I think.. Thank you for the subtitles. I encourage everyone who is interested in using them to download it from here as I'm not sure when I'll be able to implement them myself into the mission. Again, thank you for your work.

Since we're still on the subject of randomness... just a few days ago randomness got me caught by a guard. This is in my own mission that I'm making. The guard is sitting, and every once in a while he walks to a furnace to warm his hands. When he does that, as soon as he faces the furnace and starts warming his hands, you can sneak behind him to the other side of the room. Except this one time, he stopped at the furnace, and before he started to warm his hands, the game decided he should stretch his arms first. Because of that, he didn't turn to face the furnace as I was expecting, and he caught me sneaking... Indeed. I think random variations can be great, but imo one should be careful with varying the patrol time too much. Depending on the length of the patrol. In the mission I'm making myself, I almost made that mistake on an NPC with a very short patrol. I ended up preferring to swap one action for another randomly, so there's always an action, and the patrol time is always the same. For longer patrols I personally think maybe a variation of up to 5 seconds can be ok. Because there's also another thing to keep in mind: the player may have to wait for the AI. So I think it's better if the AI isn't randomly deciding to take its sweet time coming back or going away. Another one I think it's fine is random patrol ends: one of the guards in my mission, on one end of his patrol, will randomly stop at one of two places reading papers on the wall. But those two places are very close to each other, so the difference is minimal, but he's he's facing different directions, so there's a slight trap there. I think it's fine because it's something the player can easily pick up on. I don't mean to fully discourage the usage of randomness. Whether or not randomness is good, really depends on how you answer this question: is the player limited to just gambling forward and quickloading (bad), or is it still possible for the player to reliably anticipate the AI (good)? Keep in mind, you can make a fully predictable AI be really hard to work around, through thoughtful placement of sentinels and patrols. The goal of guard placement is to create a puzzle the player must solve. And, imo, the difficulty should be in the puzzle. Also keep in mind that certain randomness will affect what happens after the player quickloads. It's annoying as hell when it's not what the player is expecting. Thief 1 and 2 did that a lot too...

Since they both improve performance and fix other edge cases, seems enabling them might be better than not. I already did so on my end... don't mind a few inaccurate edges even if I wish those didn't happen either, happy for the extra FPS plus fixing self-shadowing issues I have also noticed now that I think about it. Actually I'm curious about something: What if we gave that option 3 modes, so only front faces or backfaces or both cast shadows? I remember once reading that in some circumstances, you can get better results by only computing shadows out of backfacing given they're closer to what's casting them and you don't need shadowing inside an enclosed model.

OK, I guess I'm asking what spawnargs will be supported. From reading the Wiki entry on them I don't really understand how they work (but that's OK, I'm just starting to play with them). So if I decide to use them I don't want to use some feature/spawnarg that will be deprecated. The Wiki says: Which implies both 'parallel' and 'parallelSky' spawnargs are needed to create a 'parallel sky' light. Also, you suggest for 'local' parallel lights to use 'noshadows'. Does 'local' mean with 'parallel' and without 'parallelSky' spawnarg?. So I don't really understand what's actually being deprecated. Just the shadowcasting on local parallel lights? Sorry if I'm being dumb here. I have no view on whether or not they should be deprecated since I've never used them, but reading this thread it sounds like they have their uses and I should look at them.

Of course, it is one of the reasons for the decline of online forums, since the advent of mobile phones. Forums on a mobile are a pain in the ass, but on the other hand, for certain things there are no real alternatives to forums, social networks cannot be with their sequential threads, where it is almost impossible to retrieve answers to a question that is asked. has done days ago. For devs for internal communication, the only thing offered is a collaborative app, such as System D (not to be confused with systemd). FOSS, free and anonymous registration, access further members only by invitation, full encrypted and private. https://www.system-d.org

Ignoring is somewhat inadequate as you still see other members engaging in a discussion with the problematic user, and as Wellingtoncrab says such discussions displace all other content within that channel. Moderation is also imperfect as being unpleasant to engage with is not in itself banworthy, so there is nothing more to do if such people return to their old behaviour after a moderator had a talk with them, except live with it or move away. I'd be more willing to deal with it if it felt like there were more on-topic discussion, i.e. thoughts about recently played fan missions or mappers showcasing their progress, rather than a stream of consciousness about a meta topic that may or not have to do with TDM. I guess the forums already serve the desired purpose, or they just compartmentalise discussions better.

Personally have really no good opinion on this, mostly because I have almost no knowhow, on how TDM (or idtech 4 for that matter) low level render works. So I really don't know, if killing old parallel lights, would be good or not, but if you think they are more trouble than good... And how many daylight missions exist in TDM anyway? Honest question. But, to those that perhaps want to do day light, would making sun light, still be mostly the same using the parallelSky? One thing that IMO was cool about the parallel light, compared to other lights, is that it doesn't care where it is on the world, it only cares about its axis rotation, and it afaik was capable to "project" light from any direction, is that conserved with parallelSky? I'm asking because the sky part, in its name to me makes it sound, like it only can cast light in a semi-sphere, like a dome. Edit: Reading this on TDM wiki explained a few more things, it seems I was wrong when I thought parallel lights didn't cared where they were on the world, it seems they do for portal flowing at lest.

I was just reading a post over on TTLG about Thirith's experience playing Sable when he realized the game played significantly more smoothly, and the movement control was less wonky, at 30 fps than 60 fps, and then I see your post explaining just that. Edit: I should have double checked the date. I didn't realize when I clicked the thread that it didn't take me to the latest page but evidently to the last point I had read up to, which was more than 2 months ago. Sorry about that. Well it's still an interesting thing to point out anyway.

Damn, what a crazy mission. One issue with missions like this is that sharing screenshots that would accurately represent it would ruin the experience. So if anybody is reading this and considering whether to play it or not: this is very much not a standard city/mansion mission. Obviously I was blown away. My favorite moment was wondering "Are these just decorations or will I be able to jump onto them? Surely it's just a decoration." And it wasn't. I bet I wasn't alone in this. The story was a bit confusing in places (the details like family issues, not what was overall happening), but what's important is that the mission was not. It was huge and there was a lot to do, but it flowed well. What helped was that finding stuff in "act one" helped me understand the layout of things in "act two", that in turn helped me find which areas I likely missed in "act one", and I was then free to take my time and return to them. That's a concept that worked really well because the added context made revisiting the old areas interesting again, something that I don't believe any other mission has achieved to do for me. I did have to go through this thread to find some of the secrets, but that's because I generally don't replay missions and wanted to get the (mostly) full experience from my one playthrough. It did seem at one point that the mission could be completed when the player has seen maybe 50% of it, which was a bit strange, but I guess most people here would not do that anyway.

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

I looked but didn't see this video posted in these forums. It's pretty cool.

It wasn't a "sacrifice", it was a deliberate decision. People wanted the game to be as close as possible to the original, including pixelated graphics. If you ask me, the former version based on the Unity engine looked and felt better. But, hey... I guess I'm not the right person to judge that, as I never played the original, and always found that the art style of System Shock 2 is much better anyway. This also illustrates the issue with community funded games: Too many cooks spoil the broth. In game design, you need freedom, not thousands of people who want you to do this and this and that. Just take a look at the Steam forums and see how all those wimps complain again about everything. Hopeless.

Sorry, I was only reading the static code with limited understanding. It references the idActor class, so which does include the player, so it would seem it should work with the player. If it doesn't, it probably needs someone with the code in the debugger (i.e., not me) to figure out why. Yeah, but then the AI wants to move on it's own, so how can it be bound to the player without messing the player up? Sounds like a 3-legged race!

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

What I understood is that the idea of TDM was born from that it was unclear if T3 would get a level editor at the time. Source: https://web.archive.org/web/20050218173856/http://evilavatar.com/forums/showthread.php?t=268