Search the Community

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

@chakkmanAhh right so I see what's happening there. The beast is playing an "eating" animation which is making his head very hard to hit Probably similar to their crouch and maybe other animations such as the walk. It could also be that their head is just too far forward in a lot of cases. Sucks because thats a lot of animations to fix if it is indeed the problem. Thanks for finding this. I don't know if I'll have time to fix that animations soon, but as your playing just be aware when their head looks up and down, it will also change the hit detection volume. I can't tell from the video but is your blackjack raising up to signal a successful hit? It should shift up slightly if you are about to get a KO. That was integrated in 2.11

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.

I know oil flasks are not highly regarded in T3, as they introduce slapstick animations for AI, but this kind of access denial means could add interesting challenge if you can slip from some ledges and pipes. https://www.youtube.com/watch?v=b7D_X7CTlm8 Slippery surface is already available, but probably used only in frozen areas. Using special slippery paint make it easy for colour coding, like in e.g. Mirrors Edge, but red colour in this case should be repelling. Also it will raise suspicion with otherwise neutral guards if you are literally marked as a trespasser - reminds me of a police paintball ammo with hard to wash ink, so they can catch hooligans or cars later.

A few additions and observations: We may get even better results using not just distance but also the entity's size, given the rate should probably depend on how much the entity is covering your view at that moment. As this shouldn't need much accuracy we can just throw in the average bounding-box size as an offset to distance to estimate the entity's total screen space. A small candle can decrease its update rate even closer to the camera, while a larger torch will retain a slightly higher rate for longer. To prevent noticeable sudden changes, the way LOD models can be seen snapping between states in their case, the effect can be applied gradually without artificial steps given it's just a number and may take any value. It might be best to have a multiplier acting on top of the player's maximum or average FPS: If your top is 60 FPS, the lowest update rate beyond the maximum distance would be 30 FPS for a 0.5 minimum setting... along the way one entity may be 0.9 meaning it ticks at 54 FPS, a further one 0.75 meaning 45 FPS, etc. Internally there should probably be different settings for model animations and lights: A low FPS may be obvious on AI or moving objects so you probably don't want to go lower than half the max (eg: 30 FPS for 60 Hz)... for lights the effect can be more aggressive on soft shadows without noticeable ugliness (eg: 15 FPS for 60 Hz). In the menu this can probably be tied to the existing LOD option which can control both model and frameskip LOD's.

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

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!

Cannons actually EXIST in TDM; they show up in about 3 missions. One I recall actually gets FIRED - as part of the objectives. (nothing animated, blast-a-hole-in-a-wall gimmick) More obviously MINES too... so B.P. (or something LIKE it ) exists in-world. So either the Empire has banned all civilian firearms, or more likely: Nobody cared to create one as its not part of classic Thief/1,2,3... series game-play or Worse; I don't think any modders here even possess the knowledge to model, animate, script, code, texture, sound-engineer, script-more and create all the associated kinematic animations as well...need a real Doom3 expert for that. Also; Everyone forgets old Air Guns exist: https://en.wikipedia.org/wiki/Girardoni_air_rifle The early ones even LOOK 100% steam-punk, with weird iron & brass spheres for pressure - fancy nickle-iron skeletal frames galore.

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

Definitely no KO immunity per say, don't think that would even make sense here. The idea is for guards who have seen you to show signs of persistent awareness, behaving in a different way from how they normally act before knowing there's an intruder. Some could be mechanical and difficulty altering changes, like guards drawing their sword and searching over circumstances that would have initially made them mumble and move on... others could be cosmetic behaviors that don't much affect gameplay but add more realism, like making paranoid guards use different animations or look around constantly or randomly interrupt their walk cycle to show nervousness and confusion, which would also help the player gauge their long-term alert and know when to avoid a guard that knows what's up. Also my idea may not require a separate alert field after all. Alert levels are floats: I believe guards still patrol normally until alert reaches 1 which is "AI stops and looks around", we could activate such behaviors at say (alert < 1.0 && alert >= 0.5) then make the alert level taper off more slowly at low values (decreases fast from 5 back to 1 but very slowly from 1 toward 0).

TDM was never meant to be fully realistic, it would become impossibly difficult were that the case. None the less I still find myself wishing more could be done to make AI feel less like AI, especially when handling hostile encounters (usually the player). While like most aspects this could never be truly perfect, one area feels like it could be noticeably improved: Giving AI some form of long term memory, rather than just one alert level which goes back to zero after a short time. Here is the reason why I'm saying this: Walk inside your average heavily guarded mansion and step into the bright lights, making all the guards clearly see you and chase after you to attack. Once you've had enough fun repeating the process, hide somewhere and give everyone enough time to cool down. At the end of it all, hide somewhere in the shadows where you can barely be seen and let a guard walk past you: The guard will just say "is there something over there", at best waiting a few seconds and saying "probably just the shadows" before walking away... the same man that may have chased after you for 30 minutes and should by any logic know an intruder is still in the house, I mean come on Now I'm aware we have a basic persistence system: If I remember correctly an AI that's encountered the player and was alerted enough to draw their sword will have its acuity permanently increased by a slight amount. This however makes no noticeable difference as the AI behaves mostly the same. They'll keep telling fellow AI an intruder is in the area, this definitely helps but it's only a dialogue change not accompanied by noticeable modifications in behavior as you'd expect. Obviously massive modifications might be hard to do now without upsetting existing players since it would make everything harder. As such any such attempt would likely be an experiment and, if successful, a new menu option for the difficulty settings. Still I felt like suggesting my imagined solution just in case there's a point in considering tackling this. My idea: Replace the one-time bump in acuity with a paranoia level independent from the alert level... think of the existing alert system as short-term alert and the new one as long-term alert. The standard alert level of guards is slowly added to their paranoia level, thus the more time a guard spends being alert and the higher that alert is the more fear increases. Paranoia level may be allowed to decrease over time but at a far slower rate than the alert level: If an alert guard will typically take 3 minutes to fully calm down after losing track of the player, the paranoia level should take at least 30 if not 60 (real life) minutes to fully go down to minimum... even then it shouldn't drop below a certain degree after that point was reached, for instance just 50% of the maximum paranoia. This long-term fear level would have several effects on an AI as they patrol on their normal route... the ones I've thought about are: Increased acuity as they'll be more alert. This system would replace the existing simple bump we have in that regard, with a more fluid effect and also stronger effect. Increased playing of voices and idle animations: Due to being afraid the guard may talk to themselves or others a lot more frequently and babble excessively. Walking could be replaced by running for a while, even on path nodes that don't have the run flag. The AI would still patrol that same route just at a faster pace. As a map feature set by FM's: Some path nodes can be filtered by fear level, may already be possible with the simple system but I never tried it. An AI paranoid the player is still around but having resumed their normal patrol route may choose to patrol a more sensitive area it normally wasn't going to, which would be a fair way of punishing the player for being seen by having that AI start guarding a sensitive location from then on. If the paranoia level is allowed to slowly decrease, the guard may decide to go back on this decision... the player could then do something else for 15 minutes around the map till the guard abandons the paranoid patrol route. Here's an idea I like: AI randomly getting scared for no reason, thinking they see the player in every shadow even when there's nothing there. A scared guard normally walking on their patrol route would randomly become alert for no reason, typically when walking through a dark area, causing them to draw their sword or randomly run around for a second. The problem here is this effect would be random: Imagine you're hiding accordingly but a guard randomly freaks out and bumps into you, most players would find this unfair.

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.

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.

Btw. anyone seen this other System Shock remake? It's now in beta. Made in Unity: https://www.indiedb.com/games/citadel It looks even more old-school: I thought some of the dead animations look cool, because they look quite like the original sprite-based animations, but now in 3d form. I don't remember seeing anything similarly done elsewhere, https://www.indiedb.com/games/citadel/videos/citadel-enemy-status Edit: found a gameplay video: https://drive.google.com/file/d/1onXeWRwxch7GWyb7UksnZxem5sE3685W/view

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

This one is really essential: https://www.ttlg.com/forums/showthread.php?t=138607 Should work fine with the GOG version.