snatcher

I am done for this round. Here you are if you want to give it a try: https://easyupload.io/q153fc (Link expires in 30 days)

@wesp5, for your information regarding the Unofficial Patch: As far as I can tell, the set of files found in fastdoor.zip might conflict with at least two existing missions: Noble Affairs by Goldwell The Knighton Manor by Sotha I assume (?) the pk4 files in the fms folder take preference so the worst that could happen is that "quick doors" doesn't work in these missions.

Ok, thanks. At this moment we have to aim right at double slided doors. A side effect of my last attempt is that the door maintains its new time/speed until the door gets frobbed again by the player, meaning that AI will open and/or close that door faster forever. I am not sure what's the best way to address this. Is Frobbed by player? I have added, until a better solution is found, a delay of half sec before the door goes back to normal speed. Hopefully this suffices for some time. float speed_multi = 4.0; // How much faster the doors open or close void frob_door_test_thread(entity ent) { float def_move_time = ent.getFloatKey("move_time"); // default total time in sec float cur_door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec float player_velo = sys.vecLength($player1.getLinearVelocity()); if (player_velo > 90) // normal walk speed is 70 du/sec { if (cur_door_time == def_move_time) ent.time(cur_door_time/speed_multi); ent.ToggleOpen(); sys.wait(0.5); ent.time(def_move_time); } else { ent.time(def_move_time); ent.ToggleOpen(); } }

Good point. You also mentioned at some point large (and I add: or small) doors. We could probably implement a "reasonable size range check" and if a door isn't within that size range that door will open normally. Also, modded doors could have custom times/speeds. I don't know: a rusty door accompanied by a custom sound. We could also have a speed range check, and again, if a door isn't within that range that door will open normally. Something else I noticed but forgot to report has to do with double slide doors. The door you frob will open fast and the other slide will open normal. I don't know how to detect if a door has a sister / sibling / whatever

I will settle on the below simplified solution for the time being and see what happens. "Doors open/close faster when running" and nothing else. I removed the open/close status detection and I let the game stick to whatever current status the door is. I am still able to quickly close doors behind me by employing an awkward 180 degree backwards maneuver that is difficult to achieve but feels kind of natural. I think I also got rid of exponential multiplayer bug. float speed_multi = 4.0; // How much faster the doors open or close void frob_door_test_thread(entity ent) { float def_move_time = ent.getFloatKey("move_time"); // default total time in sec float cur_door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec float player_velo = sys.vecLength($player1.getLinearVelocity()); if (player_velo > 90) // normal walk speed is 70 du/sec { if (cur_door_time == def_move_time) ent.time(cur_door_time/speed_multi); } else { ent.time(def_move_time); } ent.ToggleOpen(); } Cheers!

Thanks for the heads-up! Ok. User error.

It affects all doors unless door X uses a different script, class, method, function... I suppose it could be the case of modded doors built to serve a particular purpose. I don't know the source code so I don't know. If you want take my version of the script for a spin: Download Obsttorte's second version of fastdoor.zip (a few posts above) Open with notepad (or any text editor) the file script\tdm_frobactions.script Scroll down to the bottom and replace the last bits of code with *my* code. Just pay some attention and you will figure it out. Save the file and move the def and script folders to the TDM folder. I personally use a mod activator.

A guy with a helmet signals: (this guy is tough and) no blackjacking. I have never attempted to KO a guy with a helmet because I perceived the game was telling me do not even try. Well, it turns I actually can blackjack guys with helmets for some reason (I just found out). If the point of this mechanic is that "there must always be a way of blackjacking everyone" for some particular design aspect, then the game would have done a better job if, in example, guys with helmets from time to time remove their helmets to scratch their heads or something.

Yes. If the player goes for a KO, and given the right conditions (no helmet, unalerted, facing in X direction, appropriate distance, etc), the player must always get a KO.

Since there's some demand, here is my ugly take on script\tdm_frobactions.script. Credits to Obsttorte. Quickly opening doors while crouching is disallowed Removed sound propagation Doors don't quickly close but a 0,5 sec delay remains between the moment the action is triggered and the door starts closing The issue with the exponential multiplayer remains but it should rarely happen float multi = 4.0; // How much faster the door opens float fd_delay = 0.5; // How much time should pass when closing the door void frob_door_test_thread(entity ent) { vector linvec = $player1.getLinearVelocity(); float velo = sys.vecLength(linvec); float door_time = ent.getMoveTime()/1000; // getMoveTime is in ms, time is in sec?! // [snatcher] changed velo 80 to 90 to prevent quickly opening doors when crouching if (velo > 90 && door_time > 0) // normal walk speed is 70 du/sec { // [snatcher] removed sound propagation // $player1.propSoundMod("arrow_noisemaker_active",20); // [snatcher] why 0.9? (I am not sure) Changed to 1.0 if (ent.GetFractionalPosition() < 1.0) { // [snatcher] multi moved to opening door action only ent.time(door_time/multi); ent.Open(); while (ent.GetFractionalPosition() < 1.0) { sys.waitFrame(); } } else { sys.wait(fd_delay); ent.Close(); while (ent.GetFractionalPosition() > 0) { sys.waitFrame(); } } ent.time(door_time); return; } ent.ToggleOpen(); } Cheers!

Shelved for my part. Thanks!

I tried Thief 3 and I didn't even complete the first mission. Player movement felt awful. Thief 4 isn't even in my list of "perhaps some day", so I cannot say. I checked some videos and I am not interested. I parked Thief 2 since I discovered TDM. Respect but, based on likes? On these boards? Not a problem. I am new around and keep adjusting expectations. For what is worth, I am lucky enough I got to try this in-game, and for that, I am grateful. Thanks, Obsttorte.

Hi, In my opinion TDM does very well in the audio department therefore congratulations to the developers, modders, sound producers and editors. Thanks for your great work. I may have some remarks about how some sounds are implemented but I am talking about the actual sound files here. I noticed some missions alter footsteps and other core sounds and I appreciate the effort for a change although it is arguable whether a particular sound is an improvement or not since, I guess, it is a matter of taste. The only sounds I could never get used to and make me cringe every time are the footsteps on water. I don't know if my eardrums are fubar or what but you won't hear me often saying: I hate the core footsteps on water. Luckily, member SeriousToni came to my rescue. I downloaded his Footstep Update V3 (you can find the link below), borrowed the following water sounds: sound\sfx\movement\footsteps\player\water_jump_land01.ogg sound\sfx\movement\footsteps\player\water_jump_land02.ogg sound\sfx\movement\footsteps\player\water_jump_land03.ogg sound\sfx\movement\footsteps\player\water_jump_land04.ogg sound\sfx\movement\footsteps\player\water_run01.ogg sound\sfx\movement\footsteps\player\water_run02.ogg sound\sfx\movement\footsteps\player\water_run03.ogg sound\sfx\movement\footsteps\player\water_run04.ogg sound\sfx\movement\footsteps\player\water_run05.ogg sound\sfx\movement\footsteps\player\water_walk01.ogg sound\sfx\movement\footsteps\player\water_walk02.ogg sound\sfx\movement\footsteps\player\water_walk03.ogg sound\sfx\movement\footsteps\player\water_walk04.ogg sound\sfx\movement\footsteps\player\water_walk05.ogg And oh boy, what a difference. Thanks for sharing your sound mod, @SeriousToni!

In my humble opinion, the term "realistic" should be used with caution as it seems many times it is used as an excuse simply to win an argument. I am not pointing any finger to anyone, I am talking generally. Because current technology allows for it, some things must look and feel realistic in the TDM world. - Physics: no need to explain, we aren't in the moon - Sounds: no need to explain, I guess? - Architecture: reasonable shapes, volumes and textures to identify what's what - Lightning: how light interacts with objects, whether dynamic or static This isn't probably the full list but get these wrong and we will consciously or unconsciously detect it as off. The rest is about which rules fit best to achieve X mechanic or dynamic towards the intended experience. We have head-shots but we don't have butt-shots. Who cares. The point is how to make KOs or insta-kills challenging and/or engaging, not realistic. I think.

I am adjusting from the (my?) initial vision - where everything was chaos - to what your script currently offers and how it translates to the player in different situations. The issue being analyzed remains that players cannot run and open doors organically since the game brings you to a halt every time. The rest are additions that, while related, aren't addressing the actual issue. During a chase, it does not matter whether doors propagate sound or not. You either find cover quickly or you are doomed. But I can see how sound propagation can spoil a perfectly acceptable situation. Once again you are in a fully lit long corridor, and you are cornered: a guy patrolling from one side coming your way and chances of another guy around the corner in the opposite side. There's a door at the end and you make a desperate move: you run and quickly open the door and it happens there's yet another guy inside but looking through the window. You pulled it off! This move would never succeed with sound propagation, hence it will be discarded by players as a viable option.