Search the Community

Sorry but I can't figure out examples for this scenario for Disabled, TDM or Thief styles so I assume you are referring to TDM-inverted which would mean the introduction of the experimental TDM-inverted style forced you to change primary styles. I don't know what your code looks like but from your comments I tend to believe TDM-inverted exists simply because the new code allows for it, not because there is a use case. I would actually extend the thought to the Disabled style. tdm_door_control 3. The door opens slightly, as you say. And I have to close it to open it again. When I comment about these things it is not about me, I can setup TDM to my liking. I am sharing feedback about things few, many, most players might experience at some point.

Thank you so much for the kind words and for playing! As for the skybox showing up in the main menu pause screen, yeah, that was a tough one to figure out. I never could nail down a cause. For a while in 2.13 it would just render as a pixelated black blob at times, so I think the sky box is a little bit better than that, lol. As for the cabinet, I think that is actually a bug with the new frob code, which has since been solved, I believe.

This thread is intended for discussing and reporting things about the new frob changes during beta. Most of the description below was already given in a previous thread. Bugtracker: #6658, #6668. New Frob Control Styles I have completely refactored the frob-handling code. Now, it is easy to setup different frob control styles. There are currently 3 (and a half), which you can try in 2.14 beta. Under "Settings > Gameplay > General > Hold Frob/Interact" (cvar tdm_frob_control_style), you can change the frob control style. This setting replaced the previous hold frob delay setting (tdm_holdfrob_delay), because I think that nobody would touch that value unless they want to disable the holdfrob mechanic, which can now be achieved by the new setting as well. The currently available control styles are: Disabled: No hold-frob mechanic, i.e., pre v2.12 control style TDM: Short frob is the same as pre v2.12, but long frob is a shortcut for "grab and then use" (use-type interactions) Thief (v2.12): Same as TDM, but behaviour for bodies is swapped. Body limbs are interacted with via "drag and drop". TDM-inverted: Short frob for use-type interactions, hold frob to "drag and drop" objects (when you release the mouse button, you will release the object) I always loved the drag and drop interaction with body limbs created by Daft Mugi and I wanted to see it consistently extended to all objects, which motivated the refactor. I am very happy with the result and I hope you players enjoy it as much as I do. The Thief control style will still remain the default settings, however, as I didn't want to open that can of worms. Hold-Frob Mechanic for Doors There was previously no hold-frob mechanic for doors, except for experimental manual door control feature. I have added two additional new control modes for hold-frob on doors, which you can activate through the cvar tdm_door_control. The modes are: 0: Disabled 1: Manual door fine control (experimental, existing feature) 2: Hold frob to slowly move doors. They are opened and closed alternatingly, just like regular frobbing a door, but interrupting a moving door is skipped. 3: Hold frob to slowly open doors. Additionally, I added in the ability to quickly force close a door by holding frob and pressing attack. It felt like mode 3 ("Slow Open") gave the most benefits and most direct controls to the player and pairs well with the force-close mechanic. So, I just set "Slow Open" as the default and I did not add it to the settings menu, but you are of course encouraged to try the other modes as well. The idea behind this addition is that the player can now slowly sneak and peak through a door, but then can also quickly shut the door again if the player deems the situation unsafe. This adds more skill expression and creates further immersion. 2.14 Beta Please use this thread to report any issues with frobbing (always state tdm_frob_control_style and tdm_door_control configuration), the new door control modes (please test them rigorously) and to give feedback on any of the above changes. Pinging players that previously showed interest in this: @wesp5, @snatcher, @Baal, @Skaruts, @Wellingtoncrab, @Amadeus

It exists because it always bothered me that we have this super cool drag-and-drop for body limbs (in Thief-control-style), but that it is not consistently applied to all entities. Refactoring the frob-handling code was also long overdue, as it accumulated a lot of technical debt over time, with crazy state-leakage and what not. So, I hit two birds with one stone: A clean frobhandling routine and two new frob control styles in TDM and TDM-inverted, the latter being my own personal holy grail and I am certain there will also be other players who like it. Edit: By the way, in TDM-inverted and Thief control style, unshoulder body is consistent.

A recent thread of discussion has cropped up in the TDM Discord channel and a couple forum threads ( this comment and the general discussion after it came to mind) about the usability and efficacy of Flashbombs in TDM. To wit, most people seem to think they're kinda bad because they're just a stun, which still requires you to hide in a very narrow time frame and then wait for the AI to cool off after use. One of the big upsides of flashbombs in TG/T2 was that, if you had alerted human enemies chasing you, you could drop a flashbomb and then turn around and blackjack them to non-lethally remove them from play. It was an inventory-limited opportunity to recover from failure and continue playing the game, as opposed to just reloading a save. This is a fun and proactive interaction, and I propose that we add it to TDM. Specifically, I think this can be accomplished with minimal code. After a read through the public TDM git repository, I think the most appropriate change would be to adjust the condition here: https://github.com/stgatilov/darkmod_src/blob/ac0a286561630eefee1cbb44d09d77128cd3d8e7/game/ai/AI.cpp#L11892 to read as follows: if ((GetMoveType() == MOVETYPE_SLEEP || // grayman #3951 GetMind()->GetState()->GetStr() == "Blinded") && // proposed - maybe there's a better way to write this condition like checking the type or something? ((minDotVert != 1.0f) && (minDotHoriz != 1.0f))) // cos(DEG2RAD(0.0f)) indicates elite faceguard helmet { Currently, this check does not pass for blinded AIs and they move to the if-else branch at L11903, and since they're very alert because they were actively chasing the player, they cannot be blackjacked. This change should give a flashbomb-blinded AI the same knockout vulnerability angle as a sleeping AI. Helmeted human AIs (and undead/magical AIs because they can't enter that particular mind state) retain their blackjack immunity, and everyone else can be clunked in the face as a reward to the player for spending a limited resource, not flashing themselves, and having the quick thinking to turn around and draw the blackjack. The blinded mind state lasts for about 8 seconds (I forget where I found that but its a hardcoded magic number in a Damage() function somewhere), which feels a bit short but about right, and then when the state changes the player's window of opportunity is lost. My brain kinda glazed over when I looked at the SVN checkout+compilation.txt instructions, but if I can help test or debug this with a little hand holding I'd be happy to do so.

Found a reference to #3431 in the relevant code section. So, it seems that - at least to some degree - there was some intention behind the current behavior. Sadly, no further details on why the animation was not extended. Did that simply not occur to grayman?

There are 8 missions + Displacement I think. It's either nothing (because reading mission.cfg should be deleted in the code), or "something" just like now. I prefer the first case.

So in the museum, the code for the safe is , but looking at it with the , doesn’t reveal it. Also in the museum, I can't figure out how to open the display case

Or alternative solution is to replace mission.cfg with cvars.txt with a different format (just cvar + value instead of "set" commands) and handle it directly, with a completely separate code. But this probably won't happen in 2.14.

I never looked at TDM's source code but something like this usually happens when ray-cast is used instead of shape-cast.

Mandrasola is a small sized map in which aspiring thief Thomas Porter steals some herbal products from a smuggler. The mission was created by me, Sotha and I wish to thank Bikerdude, BrokenArts and Ocn for playtesting and voice acting. Thanks goes naturally to everyone contributing and making TDM possible. This mission occurs chronologically before the Knighton's Manor, making it the first mission in the Thomas Porter series. Events in chronological order are: Mandrasola, The Knighton's Manor, The Beleaguered Fence, The Glenham Tower and The Transaction. The winter came early and suddenly this year. Weeks of strong blizzards and extremely harsh cold weather hit Bridgeport hard. With the seas completely frozen, a rare occurence indeed, most of the City harbor commerce has stopped completely. Vessels are stuck in the ice and no ship can leave or enter the City, resulting in the availability imported goods declining and their prices skyrocketing. One of these imported items is Mandrasola, a rare herbal product, which is imported overseas from the far southern continents. Mandrasola has its uses in alchemical cures and poisons, but mostly this substance is used for its narcotic qualities by commoners and even the nobility. The problem with Mandrasola is that excessive use is extremely addicting and the withdrawal effects are most grievious. Many are utterly incapable of stopping using Mandrasola and are transformed into quivering human ruins if they do no get their daily dose. And now this expensive and rare substance is running out from the whole City. Me and my fence, Lark Butternose, would love to grab this monopoly to ourselves: selling the last few doses in the City would probably be worth a fortune. According to Lark's sources, there remains only one smuggling lord who still has Mandrasola in stock. The problem is that this individual maintains an exclusive clandestine operation and only supplies a few nobles. Despite our best information gathering efforts we couldn't learn who the smuggler is and where he or she operates. Luckily we have an alternate plan. While searching for Mandrasola related information, we learned that a noblewoman called Lady Ludmilla is addicted to the substance and has paid high prices for small amounts of it. We also know that she has visited frequently someone in the Tanner's Ward waterfront, and since she goes to the area personally we believe she is visiting the smuggler. The plan is simple: I must monitor Ludmilla's most likely entryway to the Waterfront and then follow her to the smugglers hideout. I'd better be very careful around Ludmilla. She must not realise I'm following her or she probably won't lead me to her dealer. Hurting her is also out of the question. After she leads me to the smuggler's hideout, I can take my time to break in carefully and steal all the Mandrasola I can find. While I'm there it wouldn't be a bad idea to grab some loose valuables as well. I've now waited in the blistering cold for a few hours already. Looks like there are a few city watch patrols in the area to complicate matters... I think I heard a womans voice beyond the north gate. That must be lady Ludmilla, I haven't seen many ladies in these parts. I'd better get ready.. Links: Use the ingame downloader to get it. WARNING! Someone always fails to use spoiler tags. I do not recommend reading any further until you've played the mission.

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:

@Mike__ could you please put this in spoiler tags?

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

Since TDM 2.14, there are global macros/defines which reflect the version of the TDM engine. The defines should be available everywhere in game scripts and in GUI scripts. Their values are like this: #define TDM_VERSION 214 #define TDM_REVISION 10969 #define TDM_VERSION_FULL (TDM_VERSION * 1000000 + TDM_REVISION) All of these versions grow monotonically. TDM_REVISION is the SVN revision of the source code repository. Of course, the final 2.14 release will have different value of TDM_REVISION. You can use TDM_VERSION to distinguish between major public releases, and in principle you can use TDM_VERSION_FULL to distinguish dev builds and betas. These macros add more flexibility in making missions compatible with different versions of TDM. I don't think mappers need to use them. It is more useful to the mission maintainers who can now absorb small breaking changes more easily. Here is the specific example it was implemented for: X-ray glasses breaking change. TDM 2.14 no longer applies tonemapping / gamma / brightness to UI elements. Achieving that required more refactoring in X-ray GUI. As the result, it became necessary to handle X-ray overlay in a special way in the engine. But the old way of creating X-ray overlay was not special at all, the engine could not understand which overlays were created for X-ray! So I had to add a new script event createXrayOverlay. Thanks to the version defines, it is possible to fix missions in such a way that they continue working both in 2.13 and in 2.14: #if TDM_VERSION_FULL >= 214010967 overlayHandle = $player1.createXrayOverlay(getKey("gui")); #else overlayHandle = $player1.createOverlay(getKey("gui"), ZOOM_GUI_LAYER); #endif Since TDM 2.13 and earlier do not have these macros, the C preprocessor assumes they to be zero there. The condition evaluates to false, and preprocessor removes the first line and leaves only the second one. In TDM 2.14, the condition will evaluate to true, so the preprocessor will leave the first line intact but delete the second line. P.S. This exact approach is used for compatibility in C/C++ programming with builtin macros like _MSC_VER and __GNUC__.

After deselecting the mission and selecting again I see it now. There is indeed a Full setting. But when I enable Volta 2 this setting is set to normal on every (re)start of tdm. Edit: There is a mission.cfg file in cauldron_v2_2.pk4: set pm_walkspeed "70" // increase player walk speed set pm_runmod "2.35" // increase player run speed //set pm_jumpheight "56" // increase player jump height set tdm_fwd_jump_vel "100" // increase player running jump velocity set tdm_lod_bias "1.0" The code set tdm_lod_bias "1.0" is cousing this. Not sure the file should be in there at all, potentially overriding player choices. Volta 3 has the same file with contents present. Hazard Pay does not.

For the people eager to play with the latest state of development, two things are provided: regular dev builds source code SVN repository Development builds are created once per a few weeks from the current trunk. They can be obtained via tdm_installer. Just run the installer, check "Get Custom Version" on the first page, then select proper version in "dev" folder on the second page. Name of any dev version looks like devXXXXX-YYYY, where XXXXX and YYYY are SVN revision numbers from which the build was created. The topmost version in the list is usually the most recent one. Note: unless otherwise specified, savegames are incompatible between any two versions of TDM! Programmers can obtain source code from SVN repository. Trunk can be checked out from here: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ SVN root is: https://svn.thedarkmod.com/publicsvn/darkmod_src Build instructions are provided inside repository. Note that while you can build executable from the SVN repository, TDM installation of compatible version is required to run it. Official TDM releases are compatible with source code archives provided on the website, and also with corresponding release tags in SVN. A dev build is compatible with SVN trunk of revision YYYY, where YYYY is the second number in its version (as described above). If you only want to experiment with the latest trunk, using the latest dev build gives you the maximum chance of success. P.S. Needless to say, all of this comes with no support. Although we would be glad if you catch and report bugs before the next beta phase starts

The electronic keypad is something I've wanted for a long time, along with laser tripped alarms which are next on my TODO list. I'm happy to announce they're a feature I just finished as part of a futuristic campaign I began working on! The version included here is extracted into an individual pk4 for other mappers to use. I may improve mine over time like using a GUI for the screen, for now this is a simple but finished version which does exactly everything intended. It consists of the custom script and def, models created and exported from DR reusing existing sounds and textures (only text labels had to be created), as well as prefabs for model sources and quickly placing a keypad on your map (broken or unpowered versions included). The device is operated using 12 buttons forming a numeric keypad inspired by old mobile phones, stand close look at each key and frob to input: Give your keypad a "text" spawnarg to set a password (multiple codes supported), entities targeted via "trigger_on_success" will execute when the correct code was typed, you may also set "trigger_on_fail" spawnargs to trigger targets when a bad code was written. Existing input can be cancelled with * and must be confirmed using the # key at the end, once unlocked pressing any key will re-trigger targets and lock the device back up. One aspect I'm unhappy with: I couldn't find a way for the script to directly access the entity triggering it. Because of this I had to define an additional "atdm:target_callobjectfunction" targeted by buttons which itself targets the keypad. This is only an annoyance for sanity's sake as I hoped I'd only need the keypad entity and individual buttons, yet there's also a little yellow cube sticking around which every button has to go through. Let me know if you're aware of a way to work around this; I know the script can use sys.onSignal(SIG_TRIGGER, self, "foo::bar") to run a function when triggered, but there doesn't seem to be a way to access the entity doing the triggering which is required to know which button was pressed and get its symbol. Here's the initial version with a few screenshots of how it looks and works. Feel free to use them in your FM's and share the result here! I'd love to see missions where you need to find codes in readables and remember them to access places, even having to piece them together from different sources... remember you can also use short passwords which are typed like an SMS hence the letters on the keys, for example "abe" would be "11122" (a = 1, b = 11, e = 22) 0 acts as space though I wouldn't write long sentences as they can be annoying to type in. electronic_keypad_v1.0.pk4

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

Exactly ... we recreated most of the Thief mechanics ... even some were not use in final version and remain in a code as experimental ... like rope arrow

I've read about this before here on the forums, even when the contest had just recently concluded, but reading about it in greater detail years later is certainly interesting. Thank you. It's a pity that it was mostly the marketing people who were involved on the Square Enix side, as I had the impression it was also the devs at EM that had played Requiem and all the other submitted missions and really liked them. I suppose it was as well, but the TDM team mostly heard from the marketing people. Yes, I wanted to note that as well. I even remember how the people over here in the TDM forums were sort of laughing at the fact that the results of the contest were favourable to TDM and had, in a sense, "proven" TDM as a worthy freeware successor to the Thief IP, with all the modding and mapping tools at one's disposal and so on, whereas Thief 4 or Thi4f or whatever Square Enix were calling it at that point, offered no such possibilities. The entire contest, while no doubt declared in good will and something I actually appreciated seeing, was such a self-own for Square Enix, ultimately to the detriment of them trying to bring back and market the reboot of an older IP. Even if Thief 2014 was a terrific reboot (which I doubt it would ever be), it would still have been hampered by people learning about modding being impossible, and looking to the trilogy and to TDM instead, to make new Thief-style stealth gaming content. Still, I appreciate they recognized the quality's of Moonbo's Requiem FM. Given many retrospectives I've seen over the years, gradually, on the 2014 Thief reboot attempt, one thing a surprising amount of them shared was noting how the game didn't feel cohesive in concept and execution, at any point. Not only not to the same level as the Thief trilogy, but also not even at the level when you consider it as an individual game, a new game on its own. Errant Signal, who's not some deep Thief fan, replayed the older games and played the reboot back when it came out, and made this exact observation already a decade ago. The reboot was just all over the place, in every department, felt clearly unfinished or rushed, and the most interesting story would be the behind the scenes at Eidos Montreal, on how mismanaged the entire project became over the course of several years. I think it's telling that, while even heavily discounted on GOG.com, Thief 2014 hasn't been selling well there, nor attracting much interest, whereas the original trilogy sells for figurative (and sometimes literal) cents on that same site - you can buy the whole trilogy for a smaller price than the reboot, which is kind of hilarious - and continues to have great sales and is considered one of the all-time bestsellers. Same here. I concur with demagogue that the actual Eidos Montreal devs behind Thief 2014, at least those who cared enough to make it at least somewhat presentable and playable - even if the actual game directors never got their act together and never decided on a consistent design approach - those would have been much more interesting to be in contact with, even regarding the fan mission contest. The sad truth of the matter is that all too many big publishers these days, especially those formed through larger mergers, like the Eidos buyout by Square Enix, are often marketing-first, interest in developers, and veteran players and new players alike, second. I still remember the sheer amount of money spent on pointless external marketing for Thief 2014, all the while that reboot attempt never really coalesced into anything that felt consistent (rather than throwing everything at the wall, in a panic, hoping something would stick), and was also plagued by all manner of technical issues. Just an overall embarassment, and I'm not surprised that even very lenient-leaning game retrospectives of that reboot attempt. The fact that the Thief IP has been sold away to Nordic Games and Embracer in more recent years, with Square Enix no longer caring about it and other older game IPs, also says a lot. Given the Embracer Group's own woes and bad decisions, I'm not sure any new development team will ever attempt another installment of Thief, even if it was a second reboot attempt.

Subtitle capabilities available in 2.10/2.11 are described in the wiki "Subtitles". For info about one new project using these capabilities, see the thread "English Subtitles for AI Barks". That project includes development of a TDM subtitle style guide. The thread here is mainly focused on ideas that would require future engine changes to implement. A. Automatic Switching Between Subtitle Languages Based on Settings This is a follow-on of a forum discussion between datiswous and Geep. It is desirable to have a standardized method for: subtitles to be authored in multiple languages, and so packaged and distributed as part of TDM and its FMs a gamer to dynamically select subtitles in a desired language The subtitle language choice might be controlled by the existing TDM language choice within Settings, or a separate "Subtitles Language" setting. B. Other Possible Improvements Requiring Engine Changes Most of these involve allowing the subtitle code to know something about game entities, and convey that to the gamer. Examples of useful knowledge: the ID of the speaker (or other source) the location of the speaker, relative to the player, the player's view, and other speaking AI. This type of information helps to disambiguate when there are multiple voices present. There are lots of ways such info is visually conveyed in other subtitle/caption systems, and might be added to TDM. C. Providing Subtitles for Existing FX These would have the "verbosity effects" subtitle tag. Beyond 2.11 capabilities, some of the location aspects of (B) would be pertinent.

I am all for it, especially since I have done another pass at refactoring it, yesterday. Now everything in the frob handling code is super tight and explicit, and with the new door control features and the flash bomb changes, we now actually have some cool new gameplay features for the player. Anyway, ultimately, it is stgatilov's call whether it will get included or not and I don't want to be too pushy.

I think the enemy AI already has the disadvantage of being just a bunch of code that can't compete with humans in the way of thinking and adding the KO arrow will only make this disadvantage even bigger. I's like having a good puzzle but adding auto-solve button in case if someone doesn't know how to deal with it.

Didn't ObstTorte code something like a key chain years ago? Why was it never used?