Search the Community

Impossible to miss. Read their feedback. Anyone playing the game knows to interact with things that are highlighted and that the primary way to interact with things is to frob them. What they don't know is there is an entirely different control layer in the game which provides different interactions: "use item to shoulder" being the example we are discussing. Long press is still a complex input in this regard and it is not the proposed solution to the added complexity in the game, it is a proposed way to manage that complexity from a single input. It is the tying of the familiar input (frobbing) to the familiar result (interacting with a body to shoulder it), and then tying the unfamiliar "new" input (long frob/double click/use item/etc) to the unfamiliar "new" result (using a interaction modifier to do fine grain manipulation of the body) that is a potential solution to this. That is not to claim it is perfect. Shouldering/dropping bodies is an essential player action. There are missions, such as volta 2, where shouldering a body is essential to complete the mission. There is no example I am aware of where fine manipulation of a body is ever essential - it is a nice additional layer of control. So why is fine control of bodies the first thing many players will learn? Maybe because the mod launched without shouldering or something? (I played it when it came out and am not sure if this was the case or like these new players I just didn't know it was possible, but I used to just drag bodies everywhere) Maybe it was to show off some of the physics interactions that were new to the mod vs thief? I am not sure. I am sure it is not working for some players. It did not work for me. When I came back to try the mod in 2019 it took many missions for me to stumble upon this input combination (I remember it quite clearly - it happened on accident while I was playing my now favorite mission “Perilous Refuge”). And yes I had played the training mission - multiple times.

What do you think about my suggestion, which I mentioned often enough, that long frob shoulders a body and drops it? Chances are very low that you encounter another long frob situation while shouldering a body when your hands are tied.

I would like to make sure we are on track to solve the issues at hand. Is there agreement that new players struggle and often quit playing TDM due to its current control scheme? Note the player complaints on the first page. Is there agreement on this proposal's main objective? Make TDM's "frob" and "use" interactions simpler for new players while also improving it for longtime players. I should point out that "improving it for longtime players" does not mean that every single longtime player will get a new control scheme that they are satisfied with. They might have to continue to use the "TDM 2.11" control scheme or learn the new one, even though they don't entirely agree with it. Again, the main objective is to "make TDM's frob and use interactions simpler for new players." Is there agreement that the following issues need to be solved? How can the control scheme be made less cumbersome? How can bodies be shouldered without first dragging them? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can so much key pressing and mouse clicking (currently in TDM 2.11) be eliminated? @stgatilov Are you in agreement with this proposal's main objectives? Even if you disagree with long-press frob, is it ok to include long-press frob in 2.12 dev if players want it?

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!

Another reason for long-press frob for special action: 2.11 already has one, multiloot. Quick-press frob to loot. Long-press frob to multiloot.

Maybe I'll try make a double-click prototype? Indeed, I don't have 7 months, so it won't be anywhere as polished as this proposal, but perhaps I could make something enough to understand how it feels. The double-clicking can be made generic, so that we would probably be able to assign other actions to double-click. P.S. I think I only saw long-click thing on touch screens, and there I always see some kind of circular progress bar which explains to me that holding the button will do something special. But that's not something suitable for TDM unfortunately. And yeah, I cannot easily google up discussions regarding long-click with mouse.

Oh no, you are changing the controls scheme. Previously body grabbing was toggle-like behavior (click to toggle between grabbed and not), now it has hold-like behavior (has to hold to drag body). Previously clicking a body did not shoulder it, now it does. Previously holding the click slightly longer did not cause a different action on a candle, now it does. The old controls scheme is consistent: you click to grab/ungrab, then you Enter to perform action on the grabbed object. The double-click scheme is also consistent: you still click to grab/ungrab, but now you also have double-click to combine grab + action. The proposed scheme is totally inconsistent. Clicking on an object grabs it, clicking again ungrabs. Clicking on a body... shoulders it... why? Then clicking again does not even unshoulder it. Long click on a candle extinguishes it without grabbing, but long click on a body grabs it... why? So you hold you mouse for grabbing bodies, but for grabbing candles this does not work... why? Sooner or later someone will come and say that objects should also be grabbed by holding, since bodies does so. And we'll make excuses like "you know, body grabbing is garbage and nobody needs it, but grabbing objects is different, so we just made different controls, and now making them similar won't work". I like the idea of making instant-shoulder and candle extinguishing easy to do, but the exact controls scheme is something very strange.

I don't pay attention to this argument, sorry. I can agree that grabbing bodies has little gameplay utility and is something like an engine show-off. But situation with candles is different: both grabbing and extinguishing are useful. Click vs Long click, irreversibly extinguishing candles accidentally, eternal arguments about exact duration --- this confusion is removed with double-click. And new players have equally low chance to discover double-click and long click, unless it is explained somewhere. UPDATE: And the double-click approach does not change existing controls, only adds new meaning for the second part of double-click.

Well I've finished it in the end. Overall an enjoyable and hugely impressive mission with my favourite area being the Cathedral. My problem with this mission was that I felt everything was too big, first the sewers although not too much of a maze I found them frustrating because if you didn't find the next item you needed to proceed it could take you an age to find that item with almost everywhere looking the same I found myself too easily lose my bearings. The Town was easier but I felt went on for too long, as again the forest was too big for my personal preference, again I spent an age backtracking looking for that elusive cave or side pathway. As for the Cathedral I found that to be the perfect size, I was expecting after the town to come across a monstrously sized building that went on for ever so was pleasantly surprised and it looked great. Yes I found everything in the end (with a few hits from the forum) but I get greater satisfaction from missions that tended to be less spread out, smaller being better IMO, others I'm sure prefer the opposite. The puzzles were spot on, I'm not that keen on tough mind bendingly painful puzzles but everything in this mission was fair and reasonable, with books and hints easily found and near to the actual puzzles themselves, so thank you for that. I didn't achieve the loot target (about 400g short) thankfully that was an optional goal, and I only achieved 1 good deed, obviously my experience as a TDM players is sub par, I really ought play more. Anyway thanks for one whole day lost wandering around your monster sized mission, it was great fun overall and I look forward to your next mission.

I just tested the Windows version that was uploaded on the latest 1.12 rc, but I get confusing results. Like when I frob a candle with holder, short frob will take it and long frob will extinguish it. When frobing a body it's the other way around though, short frob will shoulder it and long frob will take it. Short frob on the latter also gives the impression that the body is shouldered very quickly! I suggest to swap this and fix both issues in one go.

I don't think they're trying to make anyone believe it's 1800s Thief: the trailer is mostly blowing zombies up and away with an explosive Sharps and a coach gun. I appreciate that this is a forum for a Thief fan game, but from what little I've read it seems like you guys are very cynical here. Games should be celebrated in their own right, and not how they match up with a 25 y/o game because they share a VA. I played it all the way through thanks to this post and had a great time: it's part Resident Evil, part Deus Ex and part Hunt Showdown, all of which are fantastic. I'd have liked more enemy and weapon variety, but it was a very fun 8 hours.

I coded this up tonight to try out the idea. I think you're right. It does feel better and more consistent. Candle/Lantern (in world, not picked up) Quick-press frob to pick up. Long-press frob to extinguish (or toggle on/off). Candle/Lantern (in hands, already picked up) Quick-press frob to drop. Long-press frob to extinguish (or toggle on/off). I'll do a bit more testing tomorrow, and if all goes well, I'll update the patch.

In the light of a post by Obsttorte, I am opening a dedicated topic for discussion: Some thoughts of mine, trying to keep existing mechanics in mind: The feature should work with regular, standard doors only: avoid sliding / custom / fancy-opening doors... Locked doors will stop you to a halt, obviously. The door-opening animation must be way faster, obviously. Because doors can open towards you, we will probably have to make doors frobable before their time (when running). Forget, at least for now, about "slamming doors close" when running. Not only it is difficult to achieve with the mouse and keyboard but it would make AI following you look clumsy (unless they learn to slam doors as well). Let's not think about "slam door sounds" for now. Current sounds perhaps work just fine. And now the fun stuff: To keep things simple, slamming a door open would make AI react just like if a heavy object was thrown to a non-carpeted floor in that point. AI that is right behind that door gets pushed away (if the door opens towards them, that is). What's important here is that nearby AI get out of your way. We can further elaborate the idea: On duty: AI gets pushed and fall to the floor but stand up right after OR AI gets pushed and goes into "flash-bomb" mode. Civilians: Random possibility for civilians to remain permanently knocked out on the floor? Undead: I don't know. Zombies get torn to pieces? Discuss!

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!

Agree with you 100%. Maybe wait for a big sale. After not playing Thief for such a long time it never gave me the same goosebump feeling I got from playing The Black Parade. Blood West gets repetitive very fast and for me the difficulty is bit too much (but I also suck in soulslike games, so it might just be me).

Graven looks interesting. I hope that it IS interesting though. Added to my long wishlist...

Thanks for the replies, gonna try those spoiler Tags again now for my short review (oh well it inserted one above my text now and I can't seem to delete it on mobile - this text editor is strange)

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Just finished this mission and wow I gotta say in great honor to Grayman and of course the rest of the team picking it up, this was something I've never seen before in any other TDM mission, especially visually wise. I am so happy that grayson gave green light for other experienced mappers to finish his last mission. And what came out of this is really something special. I'll put my review in spoiler tags since I'm now referring to critical mission details. Edit - How do I put spoiler text here on mobile?? [spoiler] test [/spoiler][SPOILER] test [/SPOILER] [spoiler[spoiler [sfah

I would like feedback on the default "tdm_frobhold_delay" of 300ms. Is that: too long? too short? just right? I personally like 200ms. I made the default 300ms, because I thought some players might click a bit slower than me, which might cause them to do the long-press frob action unintentionally. Which delay do you all prefer? @AluminumHaste What are your thoughts?

I don't really see a reason this would be an issue in SLL. It be nice to see the feature in a dev build so more players (like me) can test it. Sort of like how we did testing with the frob highlight. I also don't see a reason why there would be a compatibility issue either. Leveraging this sort of short press/long press for different commands on the same input already exists for gamepads in the TDM controller config. As daft says in his post if the delay CVAR is set to 0, then there is no delay for the additional command and the original behavior for all the interactions is restored. But again it’d be nice to try it.

Yeah. I would expect the same mouse click to drop the body then. This is how I imagined this to work: Short click to frob, long click to frob and use. And also long click to drop the body, if you're carrying one.

That makes no sense at all to me. How does it work with candles? Short click picks them up, and long click douses them? Or also the other way around? Edit: Nevermind, I just read the OP again, and, it seems to work as intended. Doesn't really make sense to me that way, as I would have guessed it was the other way around, but, whatever. It would be less of a change if a short click still did what a short click did before, but, a long press would replace the two key necessity. At least that makes more sense to me. Don't know how you see it. Maybe there's something I'm missing.

There was an idea to add two features to GUI scripts (6164). The first one is runScript command, which allows GUI script to call a function from game script. Interestingly, this feature is already supported in the GUI engine, but the game code only processes this command when the player clicks left mouse button on the GUI (i.e. usually it works in onAction handler, but not in namedEvent or onTime handlers). Obviously, ID initially did not envision runScript as a global feature which works the same way everywhere, their idea was that it is context-sensitive, and whoever calls the GUI code can then pull the commands generated by the call and do whatever he wants with them. I'm not sure I really want to change this architecture... Anyway: what are the possible use cases for runScript command? The second feature is namedEvent command, which simply generates/calls a named event with specified name on the whole UI, which can be then handled by matching onNamedEvent handlers. However, this command can be implemented in several ways: Whenever namedEvent command is executed, the named event is processed immediately. The rest of the script (after namedEvent command) is continued only after generated named event is fully processed. Whenever namedEvent command is executed, named event is put into some kind of queue, then the current script continues to execute. The generated named event is executed at some moment later, but surely on the current frame. The point 2 can be further differentiated on the exact order when generated named events are processed. So the first approach is how functions normally behave in normal imperative languages, with a real call stack. The second approach is delayed execution, like what we currently do with "resetTime X; -> X::onTime 0 {...}" combo (at least everywhere in the main menu GUI). My worry with the first approach is that it is an major change for GUI engine with no past experience, and it will probably not match well with the long-established GUI wierdness (I mean e.g. the wierdness that all expressions in GUI script are executed before the script commands start executing). And it would work different both from the "resetTime + onTime 0" combo. On the other hand, the callGui in game scripts do execute named event immediately. And I must admit nested GUI calls could be used to reduce the issues from the GUI weirdness mentioned above. Also, this command exists in Quake 4, but I'm not sure how exactly it works. And it's probably good idea to make TDM work the same way.

Just FYI: You just replied to a more than 4 and a half year old post. Posted by a member who was last seen online here more than 4 and a half years ago.