Search the Community

That is correct, sorry. I might make a separate thread with my suggested solution later, this question seems to come up a lot.

Folks please let’s not necro a lengthy discussion on the merit of save restrictions in general in Kingsal’s release thread, when it’s well represented elsewhere.

I loved it. Awesome game. I faceplanted at the people who asked for quest markers in the Steam forums there... Herr, lass Hirn regnen. The game is so great, and so true to the original, because it doesn't hold your hand. When is the new breed of gamers gonna learn.

Kinda feels like I threw a live grenade into a dung pit by necroing this thread. Anyway, it seems like there is some agreement with my current work on both sides of the pit, as it will make the control scheme a bit more consistent, while leaving the general new control scheme intact. I have a working prototype that implements the following table. Contrary to the previous table, hold-type-grabber for loot and tools is not possible, as the long-press frob is already tied to multiloot (pickup multiple items successively without releasing the frob button). This extension is enabled via cvar, i.e., completely optional.

It isn't. That is Snatchers angle, who likes to hide bodies under benches and similar. My point of view is only that the behaviour should be consistent, which it currently isn't. I said that over and over in this thread :)!

@wesp5 Make sure you skip thief, thief2, deus ex, dishonored, dishonored 2, etc. Not sure what military grade hallucinogens they were smoking but they all have physics object you can pick up and bodies you can shoulder - tied to the same input! It was quite the scandal - all anyone could talk about at the time is “why don’t the bodies just float in front of my camera when I pick them up just like this potted plant does?” What they didn’t have that the current build of TDM does was the ability for players like you turn this troublesome development off in the main menu. Thankfully I am absolutely certain you’ve been spared the pain of playing of these games, as it is seemingly the only explanation I can come up with for you to still be posting the same comments over and over and over again in this thread. Seriously though these interactions in the game were never really the same thing, you do not drag most physics objects in the game slowly along the ground, you pick them up kind of like how shouldering the body is a non goofy way to display you have picked it up, so no idea how it is inconsistent and even why that matter so much.

A couple more: https://forums.thedarkmod.com/index.php?/topic/21739-resolved-allow-mantling-while-carrying-a-body/ https://forums.thedarkmod.com/index.php?/topic/22211-feature-proposal-new-lean-for-tdm-212/ https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/ https://forums.thedarkmod.com/index.php?/topic/22249-212-auto-search-bodies/

This pinned thread's purpose is to collect links to all the discussion threads for new features to be added in 2.12: [2.12] Multi-addons support [2.12] Auto-search bodies [2.12] Turrets Allow mantling while carrying a body New lean for 2.12 Frob to use world items [2.12] Viewpos on player HUD and screenshots English Subtitles for AI Barks Subtitle Enhancements [2.12] Improved Interaction Culling and a related bug report thread HERE As well as older feature collection threads: [2.10] Feature discussion threads [2.11] Feature discussion threads

Thanks for summarizing the most relevant arguments. Saved me from reading this monster of a thread in its whole. It is obvious that a lot of thought from a lot of smart people has already gone into this. Still, it kind of rubs me the wrong way that the grabber-interaction with bodies is so fundamentally different than the rest and it frequently annoys me that I can't hold-type-grab junk objects as well. So maybe, to catch two flies with one stone, the hold-type-grabber-interaction just needs to be added to a few more entity types. In other words, stick to the frobbing-rules you guys developed in this thread, but additionally add hold-type-grabber-interaction to Junk and Tools, and if possible, Loot as well. Entity type Short Press Long Press Junk Toggle-Grabber Hold-Grabber Food Toggle-Grabber Eat Loot Pick-up Hold-Grabber?? Bodies Shoulder Hold-Grabber Lights Toggle-Grabber Exstinguish Tools Inventory Hold-Grabber (Highlighted interactions in the table differ from the new control scheme)

Unless I am missing something the only really difference in this table vs the current implementation would be inverting the shoulder/grabber behavior for bodies (I guess it also removes the fall back on long press to do the default action on things like junk - not sure if it is actually preferable for some reason to just do nothing in these cases). Switching the body interaction to shoulder on frob is one of the foundational elements of this change and judging by the polling information is supported by a majority of players. The reasons for this change are well articulated in this thread, but the short version is that this has been confusing new players for years who actually think there is no shouldering mechanic in the game at all. The first thing the game shows them is fine manipulation of bodies via the dragging mechanic, and they must learn to use an unfamiliar key combination to actually carry one. This is only described in a easy to miss readable in the training mission. I am myself only learned of this mechanic after playing several missions and by accident. You can read accounts of players literally giving on the game elsewhere in this thread. I imagine they would potentially support this change as well. Which is the more common action a player must undertake in the game - shouldering a body or manipulating limbs and slowly dragging it around? So if that is the only element of the implementation which is “inconsistent” (again I don’t think this is actually important - shouldering is the primary interaction with bodies in almost every other similar game and this confuses no one) then I think it’s a pretty small tradeoff for a pretty big pay off.

I get that and full disclosure: I did not read the full thread, it's just too much! I was absent in recent months, so I missed all of this. That makes a lot of sense. Although, to solve this, one could communicate via audio cue ("uh uh") that no use-type-interaction is available for that entity. Anyway, there is an incredibly easy way to solve the inconsistency while staying true to the original control scheme and that is to simply swap shouldering and grabber. Entity type Short Press Long Press ...Release Button Junk Grabber Nothing Nothing Food Grabber Eat Nothing Loot Pick-up Nothing Nothing Bodies Grabber Shoulder Nothing Lights Grabber Exstinguish Nothing Tools Inventory Nothing Nothing This way, every interaction that was originally "frob + use" (shouldering, eat, exstinguish) will the become long-press-frob. So, the long-press simply becomes a shorthand for special action, nice and clean. While I do love the hold-type-grabber to death, I'd be willing to sacrifice it for a consistent control-scheme. (@stgatilov @Daft Mugi) Right now, we have this weird mixture of hold-type- and toggle-type-grabber that I guarantee you, will confuse new players (and streamers). I say, either fully embrace the lovely new hold-type-grabber (which I am still all for) or drop it completely.

It is quite litigated in the thread already whether it is particularly important or common in games for a context sensitive input be "consistent" or whether this inherently means something is intuitive - so I won't repeat my thoughts on it. I will say It seemed like it was quite difficult to get this change as it is into the game, so while I think anything can be improved I am not sure anyone wants to go through another 10 pages, polls, etc. So I hope I don’t sound short or dismissive, it’s really not my intention, it’s just been a very long thread. I will say if an object is frob highlighted, ie subject to an interaction prompt, if frobbing it then does not do anything or provide any feedback the game immediately feels very strange and broken. I do not think it is good a idea to have objects which can only be interacted with via long press. The current design is around primary interactions being on short press and the secondary more situational actions being on hold, while also retaining compatibility with all legacy interactions. There is some disagreement as far as what is a "primary" interaction, but I find it pretty intuitive in practice as it is today. There are some exceptions that did not work out in testing. I will the example of candles/lanterns - having extinguish as the primary interaction makes a lot of sense, but in practice didn't work very well. The game is full of extinguished candles, empty candle holders, etc that are now simple physics objects that require a long press to pickup and have no primary interaction - see issue above. You also have to handle lanterns differently, which can be toggled off/on. You could code in the TDS method which is extinguish a lit candle on frob, then it becomes a physics object (“junk” in the parlance of your table) so the primary interaction should then be grabber. There seemed in general to be a lot of concern about keeping the code clean. Being able to grab moveable inventory objects on hold without having to do the current dance of bringing them into inventory first and then “dropping” them - like keys and tools - could be a nice addition. Many loot objects are not moveables so these might be a bit of issue?

After taking a gaming break for 1 week, i decided to get back into playing games yesterday especially stealth game like TDM. Coincidentally, this new fan mission appeared in the online mission archive when i was clicking "download mission" button, so I decided to download & try playing it. I like this manor/estate fan mission so far. i like the starting point of this FM where you have to venture silently into small-scale spider-infested forest. On a related note, i have sporadic spider phobia and again this mission helped me to desensitize myself to spider. I usually find the entry point to the manor disguised as a wall with loose bricks or covered with tall green grass but i have to find stone walled key for this one

I'm happy to present my first FM, The Spider and the Finch. There may be a spider, but no ghosts or undead. It should run a couple hours. It's now available on the Missions page or the in-game downloader. Many thanks to the beta testers Acolytesix, Cambridge Spy, datiswous, madtaffer, Shadow, and wesp5 for helping me improve and making the mission to the best of my abilities. This would not be have been possible without Fidcal's excellent DarkRadiant tutorial. Thanks also to the many people who answered my questions in the TDM forums. Cheers! 2023-12-13 Mission updated to version 3. Fixed a bug where the optional loot option objective was not actually optional. Updated the animations for Astrid Added a hallway door so the guards are less likely to be aggroed en masse.

The spambots are getting better. Even a more or less realistic thread title.

Haven't read the whole thread, but my theory is that this happens when you have already picked up the key the other guard (pool area) is wearing.

I know, it's just the only easy way I can think of. Fixed script names is what we have now, tdm_custom_scripts.script or tdm_user_addons.script: Every mod will use them up and thus take them away from other mods. We need something that's dynamic and unlimited. A better alternative is a prefix to indicate you want auto-running of that script: Anything called "scripts/include_*.script" would be a good one, just use an unique name and call yours "include_mod_something.script" which will work if no one else names theirs "mod_something". Even better: Have a keyword at the beginning of the script! Like how scripts in Linux start with #!/bin/bash so file managers know how to preview them: Similarly we could add something like #autoexec at the beginning of ours, though this approach requires the engine looping through all script files to detect this keyword. We could imagine making tdm_user_addons.script unique per pk4. But I haven't even mentioned this one as it goes against how the file system works: You can't have multiple files with the same name and different contents, the latest archive in alphabetical order must always override a file loaded by an earlier archive. What gets close to that is a special text file in each pk4 like a package.txt which references the inclusion script as a flag. FM's kind of do that with darkmod.txt: When each pk4 is iterated by the engine at startup, it could read a script name mentioned there and execute the file referenced. But this seems more complicated than necessary unless this configuration is used for more stuff, maybe to list loaded mods in the main menu with their title / description / author / version the same way missions are?

I'd like to chip in and say I think basing the script name on the archive/file name is not a good idea. Filenames are extrinsic to the mod and something you have no direct control over. Someone may unwittingly change the filename and wonder why the mod stops working. You'd be better off having a fixed script name for all mods which is, I think, what dragofer says is being considered.

Yeah, that's what I was thinking of. When FM independent mods are also circulating this is bound to happen with the current system unfortunately, realized it soon after I started delving into modding. In the mods I posted so far I include the notice that you must edit tdm_custom_scripts.script yourself and watch out for it overriding or being overridden by other mods even then. Thank you lots for this, can't wait! The best solution to me always seemed like the one I suggested: Auto-execute the script with the name of the archive, so if it's "mod_something.pk4" then "scripts/mod_something.script" is automatically ran only from that archive. Only problem is if you put things like version number in the archive's name this would require renaming the script with each update, I wonder if a slightly different way is possible like pattern matching based on any part of the name, but anything among those lines will be a godsend.

Similar: My suggestion is getting rid of needing tdm_custom_scripts.script as a requirement. The problem is that unlike every other asset, be it a def or a skin or model or texture, scripts need to be referenced from a core script file for execution: FM's each need to contain a file with that exact name including their custom scripts. The problem with this is that no mods containing scripts can work out-of-the-box as a drag-and-drop pk4, the same way that say a custom character (just AI model or skin) can: Each individual FM needs to integrate it manually, universal mods aren't possible since the last pk4 loaded will override tdm_custom_scripts.script or tdm_user_addons.script breaking all previous mods referencing their own scripts from those files. The ideal solution would be just auto-loading scripts like everything else. But I imagine this may no longer be possible as it could break a lot of existing things like older FM's. One compromise I believe I suggested was allowing a dynamically named script to be auto-loaded by the engine, which would make it so different pk4's don't override the exact same file and conflict with each other: If your mod is named "whatever.pk4" for instance, the engine should auto-execute the script named "scripts/whatever.script" located in that archive... this would provide an elegant and equally sandboxed solution to this long standing issue.

Okay. Im gonna actually make these updates in the hazard pay thread and make sure everything is working.

Well, my idea does not work. In reality, the penis gets created/recreated/reattached many times: anim urinate models/md5/chars/guards/proguard/animation_urinate.md5anim { prevent_idle_override frame 1 call overrideLegs frame 30 attach atdm:penis_s penis hand_l frame 30 sound snd_rustle frame 55 reattach penis LeftHips_Dummy frame 70 destroy penis frame 70 attach atdm:penis_urinating_s penis_urinating LeftHips_Dummy frame 70 sound urinate frame 340 destroy penis_urinating frame 340 attach atdm:penis_s penis LeftHips_Dummy frame 375 reattach penis hand_l frame 425 destroy penis frame 425 sound snd_rustle } As you see, the penis is already destroyed at the end of animation. And then there are two more ways to delete it: "attach" command looks at "remove_delay" spawnarg, and if it's positive, then schedules removal of the attachment penis also has "tdm_suicide" script attached, which also checks the same "remove_delay" spawnarg and deleted the same entity after this delay from script thread. So, why do we have 3 ways to destroy the penis?

Public release v1.7.6 (with Dark Mod support) is out. Improvements since the final beta 14 are: Fixed a few remaining bugs with zip/pk4 support. Game Versions window now properly displays TDM version. Import window no longer has a vestigial off-screen TDM field (because TDM doesn't need or support importing). Web search option is now disabled if an unknown/unsupported FM is selected. If an FM with an unknown or unsupported game type is selected, the messages in the tab area now no longer refer to Thief 3 ("Mod management is not supported for Thief: Deadly Shadows"). The full changelog can be viewed at the release link. The de facto official AngelLoader thread is here: https://www.ttlg.com/forums/showthread.php?t=149706 Bug reports, feature requests etc. are usually posted there. I'll continue following this thread though. Thanks everyone and enjoy!

I have an idea. From time to time, these kind of guard create a penis during animation. This penis creates a thread during spawn, but it starts it as DelayedStart(0 ms). Instead of running the script immediately, it stores its entityNumber onto the callstack of the script thread. Let's suppose that for some reason penis gets destroyed immediately, and bow attachment gets spawned at this exact moment: then the bow attachment reuses entityNumber of the penis. At some moment suicide thread wakes up, reads entityNumber from stack, and kills the entity with this index --- but now it is bow attachment instead of penis. That's a simple explanation why dangling pointers are dangerous! However, if this really works like this, the whole scripting should be completely broken, since scripts in general often wait long time, and all the entities they reference might die during waiting. I can hardly believe this situation is always handled that bad. I'd like to ask people who have used scripting a lot. What happens if you have a local variable X of type "entity", then you do "sys.wait(1.0);", and then try to use X but it has died during waiting?

Beta 13 More robust TDM file reading attempts: we now try until we can access them or until a 5 second timeout If a TDM file is not found at all, we now continue immediately and don't wait the 5 seconds Rework auto-refresh system to be simpler and more robust: Refreshes run completely on the UI thread now Refreshes happen immediately or not at all; no more deferred refreshes Refreshes are not allowed when the main window is blocked or disabled (mostly if a progress box is up) If a dialog window is open (Settings, About, etc.) then a "lightweight" refresh (UI update only) is allowed, but a "heavyweight" refresh (FM list reload, possible scan and/or readme cache update) is not. Remove installed status from unavailable TDM FMs (those not found on disk) Gracefully handle scenarios where some or all watched TDM files or directories may not exist (clean install, partially broken install etc.) Ignore empty or invalid FM dirs (dirs with no pk4 files in them; TDM clean installs may add an empty "saintlucia" folder for example)