snatcher

If we cannot find a simple and elegant way of encompassing all items, I would restrict limit it so that we only get the animation for items that have some monetary value. Something like: ... float monetaryValue = inv_item.getFloatKey("inv_loot_value"); if (monetaryValue > 0) { // animate } ... It won't be perfect, but it will be consistent.

Credit where credit is due but no, I didn't personally ask Goldwell for permission to redistribute the the "frob_loot" sound and I didn't personally ask Goldwell for permission to edit and reuse parts of the source code from the Noble Affairs mission.

You (and everyone else) can do with what I share in these boards whatever you like. Past, present and future. No need to ask me nor credit me. Permission to have fun granted for life Unfortunately I am not yet able to create my own content and keep toying with other's creations so, for your own peace of mind, ask the others if you want. Paintings... from the little I know, paintings are simply loot and not their own entity. I checked because I noticed paintings revert to a default canvas when you frob them. It is barely noticeable now, but you can notice it if you pay attention. I wanted paintings to do without the animation and maintain the stock sound but I didn't find a way. I wouldn't call it a bug that requires a fix but you are right: it doesn't work with all items. And I don't know if the animation can be (and should be) extended to more items or not. We shall see.

For "Fast Doors" check this whole topic: Slam doors open while running For "Loot Animations" check the comments in the main post. The better term is Mod Manager or Mod Enabler, sorry. A Mod Manager allows you to enable/disable mods easily on demand. There is the good old JSGME (search for it online) for casual and lightweight modifications and more modern and advanced Mod Managers for more serious modding.

EDIT: These mods are now part of the TDM Modpack. --------------------------------------------------------------------- Hi, In this topic I merge two topics that have been recently discussed: Fast doors (Topic: Slam doors open while running) Loot animations (Topic: Interaction with objects) Since the two mechanics share common libraries I merged them into a single download so that we can use them both at the same time. The set of files provided should work in any mission except: Snowed Inn by Goldwell & Kingsal Hazard Pay by Kingsal Shadows of Northdale ACT II - Down The Rabbit Hole by Goldwell Noble Affairs by Goldwell Missions above will play fine though, since the scripts they contain will override any stock or custom content. The only downside of all this is that previous saves will not work when you add the new files. You must start new missions from scratch. Consider yourself warned --------------------------------------------------------------------- FAST DOORS Credits: Idea and programming by Obsttorte. Treatment by snatcher. Description: Doors (and other items in the category) open and close faster when running. LOOT ANIMATIONS Credits: Originally found in the Noble Affairs mission by Goldwell. Programming by Obsttorte. Treatment by snatcher. Description: (From Obsttorte) "It basically moves the loot and other items towards the player a bit before putting it in the inventory upon frob, thus underlining the impression of actually taking it the way it was done in the Dishonored games. And yes, it is a script I've created at request by Goldwell." I further adjusted the script a little: Instead of moving the items towards the center of the screen, items are moved towards the body for best effect. The animation is a tad slower for best effect. Please note the download also includes the "frob_loot" sound found in the Noble Affairs mission. I find this sound fits extremely well the new animation. --------------------------------------------------------------------- DOWNLOADS AND INSTALLATION Download, unzip and move contents to your TDM folder. I recommend using a Mod Activator. --------------------------------------------------------------------- I hope someone shares a video showcasing these new additions. I am not into video editing, sorry. Thanks everyone mentioned in this post for their ideas, content and support. Much appreciated. Cheers! --------------------------------------------------------------------- Changelog: v3: Fast Doors: Removed the dependency with "tdm_mover_doors.def" to prevent breaking some missions. v2: Loot animations limited to loot that has some monetary value. Loot animations removed from paintings to avoid some errors. v1: Initial release FrobActions_Script_v3.zip

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.

Dear @Obsttorte , I have been testing v2 for some time and I don't have any positive points, I am afraid. The following are in-game sensations (didn't check or alter your scripts). Your script works fine when running away from AI, but my main testbed this time around has been a house with long carpeted corridors and AI doing its business unalerted. 1) The sound propagation spoiled the fun of the first version and AI is on me in more numbers and much faster than before. And while the idea of some noise could make sense, it doesn't translate well on screen because quickly opening doors doesn't feel too-fast or too-loud to me. The feeling is that I certainly am opening doors faster but with enough control not to slam the door against walls or frames. I like it better that AI detects me because of my floor steps and or simply because they see me. Ghosting at high speed undetected is actually fun! In addition, trying to quickly opening a door that is locked will alert nearby AI. And while it may be a realistic on paper it doesn't translate well to the screen: why is this guy coming here? 2) Players shouldn't be able to quickly open doors when crouching, but I guess this could depend on whether sound propagation stays or not. It currently doesn't feel right to me and I find quickly open doors when crouching a mechanic that may encourages players to go fast. 3) There's a situation where quickly closing doors doesn't feel right. Put yourself in a long corridor, there's a door to your right that is open. You want to close that door but stay on the current corridor, running in the same direction. You make the move but get no feedback in that split second. Weird. I say leave "quickly opening doors when running in stand up position" and forget about the rest. Less is more isn't it? That feature alone adds a lot and there's always time for upgrades. Cheers!

Thanks for your comment, @Obsttorte . I find all your posts constructive and thoughtful. Compromises vs determination. What a subject! Determination can reinforce the gameplay for your target audience and well intended compromises can leave a game in a status where neither your target audience nor casual players are fully satisfied. Geez, did I just open a can of worms? @kingsal, thanks for sharing your thoughts with us. Feedback, observations, or suggestions can be perceived as criticism. And leave the impression that a reviewer didn't like unrelated aspects of a mission, or the whole mission. Far from it in my case, I think your mission could perfectly be found, as is, in any commercial game of the genre. Once again, congratulations. One more thought or suggestion on the topic, that could be applied to this mission or others to challenge the way (some) players assess and approach a situation. Players make their way through the first stages of the mission killing Zombies if they like, nothing wrong with that. You can even use some tricks and encourage players to do it. But upon entering the main area, the player finds out Zombies are just poor miners gone wrong and, perhaps, there's hope and order can be somehow restored. Conflict is served.

You are probably right and I misunderstood what TDM was trying to achieve. I will reflect. Holy crap! Nice moves

I don't know! Perhaps the zombie just collapses for a minute and then wakes up and gets back to work with one, two, three arrows in his head. Perhaps the zombie turns to ashes or liquefies or vaporizes and a clone spawns in an obscure area of the map and replaces the previous instance.

There must be some unknown reason...